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1.  Introducción  a  la  ingeniería  del  software 


1.1.  Introducción 


Este  primer  capítulo  del  curso  Ingeniería  del  software  en  entornos  de 
software  libre,  proporciona  las  bases  para  conocer  los  conceptos 
principales  involucrados  en  la  ingeniería  del  software  en  general,  y 
su  aplicación  al  software  libre  en  particular. 


A  lo  largo  del  capítulo,  veremos  que  la  ingeniería  del  software  es 
casi  tan  antigua  como  el  propio  software,  y  también  que,  parte  de 
los  problemas  que  hicieron  nacer  este  sector  de  la  industria  del 
software  siguen  vigentes,  la  mayoría  sin  una  solución  clara  y  defi¬ 
nida.  Pese  a  ello,  se  han  hecho  grandes  avances  en  todos  los  cam¬ 
pos,  desde  la  estimación  del  coste,  pasando  por  la  gestión  de  los 
equipos  de  trabajo,  documentación,  y  muy  notablemente  en  prue¬ 
bas,  calidad  y  seguridad. 


Después  de  introducir  brevemente  los  conceptos  más  importantes, 
pasamos  directamente  a  examinar  dos  metodologías  concretas 
bastante  populares.  En  primer  lugar,  veremos  la  metodología  eXtreme 
Programming ,  quizá  la  más  próxima  a  la  forma  de  organizar  y 
participar  en  proyectos  de  software  libre.  A  continuación,  daremos 
un  vistazo  a  Métrica  v3,  una  metodología  clásica  que  es  impres¬ 
cindible  conocer  si  se  han  de  realizar  proyectos  con  la  Administra¬ 
ción  española. 


Existen  cientos  de  metodologías  (públicas  y  particulares  de  empre¬ 
sas),  pero  los  conceptos  introducidos  a  lo  largo  de  este  módulo  nos 
proporcionarán  los  conocimientos  necesarios  para  evaluar  su  ido¬ 
neidad  en  nuestro  ámbito  de  trabajo  o  proyecto  concreto,  y  para  pro¬ 
fundizar  en  los  aspectos  de  la  ingeniería  del  software  que  más  nos 
hayan  llamado  la  atención. 


11 


Software  libre 


1 .2.  Objetivos 

•  Tomar  conciencia  de  la  importancia  de  los  procesos  y  actividades  re¬ 
lacionados  con  la  ingeniería  del  software  en  proyectos  de  todo  tipo. 

•  Conocer  los  conceptos  básicos  involucrados,  que  nos  permitirán 
documentarnos  más  ampliamente  cuando  nos  sea  necesario,  y 
evaluar  metodologías  concretas. 

•  Familiarizarse  con  la  metodología  eXtreme  Programming,  y  con  los 
nuevos  paradigmas  de  gestión,  diseño  y  desarrollo  que  plantea. 

•  Conocer  la  estructura  general  de  la  metodología  Métrica  v3,  y  sus 
principales  procesos,  actividades  e  interfaces. 


1.3.  Un  poco  de  historia 


Nota 


Alguno  de  los  proyectos 
más  representativos  de  la 
época,  como  el  desarrollo 
del  sistema  OS/360  de  IBM, 
tardó  más  de  una  década 
en  finalizarse,  y  fue  el  pri¬ 
mero  que  involucró  a  más 
de  1 .000  programadores. 
Más  adelante,  el  ¡efe  del 
proyecto  en  "Mythical  Man 
Month",  Fred  Books,  reco¬ 
nocería  que  se  habían  co¬ 
metido  errores  de  millones 
de  dólares,  y  pronunciaría 
la  conocida  ley  de  Brooks: 
Asignar  más  programado- 
res  a  un  proyecto  ya  retrasa¬ 
do,  suele  retrasar  aún  más 
el  proyecto. 


El  término  ingeniería  del  software  empezó  a  usarse  a  finales  de  la  dé¬ 
cada  de  los  sesenta,  para  expresar  el  área  de  conocimiento  que  se 
estaba  desarrollando  en  torno  a  las  problemáticas  que  ofrecía  el 
software  en  ese  momento. 

En  esa  época,  el  crecimiento  espectacular  de  la  demanda  de  siste¬ 
mas  de  computación  cada  vez  más  y  más  complejos,  asociado  a 
la  inmadurez  del  propio  sector  informático  (totalmente  ligado  al 
electrónico)  y  a  la  falta  de  métodos  y  recursos,  provocó  lo  que  se 
llamó  la  crisis  del  software  (en  palabras  de  Edsger  Dijkstra)  entre 
los  años  1965  y  1985. 

Durante  esa  época  muchos  proyectos  importantes  superaban  con 
creces  los  presupuestos  y  fechas  estimados,  algunos  de  ellos  eran  tan 
críticos  (sistemas  de  control  de  aeropuertos,  equipos  para  medicina, 
etc.)  que  sus  implicaciones  iban  más  allá  de  las  pérdidas  millonarios 
que  causaban. 

La  crisis  del  software  pasó,  no  tanto  por  la  mejora  en  la  gestión  de 
los  proyectos,  sino  en  parte  porque  no  es  razonable  estar  en  crisis 
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más  de  veinte  años,  y  en  parte  porque  se  estaban  haciendo  progre¬ 
sos  en  los  procesos  de  diseño  y  metodologías. 

Así  pues,  desde  1985  hasta  el  presente,  han  ido  apareciendo  herra¬ 
mientas,  metodologías  y  tecnologías  que  se  presentaban  como  la  so¬ 
lución  definitiva  al  problema  de  la  planificación,  previsión  de  costes 
y  aseguramiento  de  la  calidad  en  el  desarrollo  de  software. 

Entre  las  herramientas,  la  programación  estructurada,  la  programa¬ 
ción  orientada  a  objetos,  a  los  aspectos,  las  herramientas  CASE,  el 
lenguaje  de  programación  ADA,  la  documentación,  los  estándares, 
CORBA,  los  servicios  web  y  el  lenguaje  UML  (entre  otros)  fueron  to¬ 
dos  anunciados  en  su  momento  como  la  solución  a  los  problemas  de 
la  ingeniería  del  software,  la  llamada  "bala  de  plata"  (por  silver  bullet). 
Y  lo  que  es  más,  cada  año  surgen  nuevas  ideas  e  iniciativas  encami¬ 
nadas  a  ello. 

Por  supuesto,  también  ha  habido  quien  ha  culpado  a  los  programa- 
dores  por  su  indisciplina  o  anarquía  en  sus  desarrollos.  La  ignorancia 
y  algunos  casos  excéntricos  contribuyeron  a  crear  una  imagen  falsa 
del  programador,  que  hoy  en  día  aún  perdura.  Aunque  muchas  veces 
él  es  el  "sufridor"  de  alguna  de  estas  metodologías  o  de  una  pobre 
implementación  de  las  mismas,  parece  lógico  que,  como  participante 
activo  en  el  proyecto,  las  metodologías  más  modernas  empiecen  a  te¬ 
nerle  más  en  cuenta. 

En  combinación  con  las  herramientas,  también  se  han  hecho  esfuer¬ 
zos  por  incorporar  los  métodos  formales  al  desarrollo  de  software, 
argumentando  que  si  se  probaba  formalmente  que  los  desarrollos 
hacían  lo  que  se  les  requería,  la  industria  del  software  sería  tan  pre¬ 
decible  como  lo  son  otras  ramas  de  la  ingeniería. 

Entre  las  metodologías  y  procesos,  además  de  Métrica  v3  (promovi¬ 
da  por  la  Secretaría  del  Consejo  Superior  de  Informática)  y  eXtreme 
Programming,  que  veremos  en  detalle  más  adelante,  destacan  mu¬ 
chos  otros  como  RUP  ( rational  unlfíed  process  desarrollado  por  Rational 
Software  Corp.  ahora  una  división  de  IBM),  SSADM  ( structured  Systems 
analysls  and  deslgn  methodology  promovido  por  el  Gobierno  britá¬ 
nico)  o  el  método  de  evaluación  de  la  capacidad  de  desarrollo  de  los 
equipos  o  empresas  conocido  como  CMMI  ( capability  maturlty  model 
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¡ntegratlon).  Paralelamente,  suelen  usarse  también  métodos  de  pre¬ 
dicción  de  costes  como  COCOMO  o  los  puntos  de  función. 

Las  últimas  iniciativas  en  este  campo  son  múltiples  y  se  extienden  a 
lo  largo  de  todo  el  proceso  relacionado  con  el  software.  Los  más  aca¬ 
démicos  se  inclinan  por  una  estructura  de  componentes,  servicios, 
con  orientación  a  objetos  o  a  aspectos  en  la  implementación;  aun¬ 
que  también  es  igual  de  significativo  el  desarrollo  de  las  herramien¬ 
tas  que  nos  ayuden  a  representar  y  compartir  estos  diseños,  así  como 
a  valorar  el  esfuerzo  y  el  valor  que  añaden  al  producto  final.  Es  real¬ 
mente  un  campo  fascinante,  donde  tanto  en  los  seminarios  o  en  las 
grandes  consultoras,  como  en  los  pequeños  laboratorios  se  innova 
cada  día  y  se  presentan  buenas  ideas. 


1 .4.  Conceptos 


En  este  capítulo,  veremos  los  conceptos  más  comunes  asociados  con 
la  ingeniería  del  software,  aplicables  tanto  a  entornos  de  software  li¬ 
bre,  como  al  resto.  Todos  ellos  disponen  de  abundante  bibliografía, 
y  de  algunos  cursos  y  másters  especializados  en  su  aprendizaje  y 
aplicación  a  los  procesos  de  desarrollo.  Aquí  únicamente  los  defini¬ 
remos  para  tener  una  base  sobre  la  que  tratar  los  ejemplos  de  me¬ 
todología  que  veremos  en  los  capítulos  siguientes. 

1.4.1.  Gestión  de  provectos 

La  gestión  de  proyectos  es  la  disciplina  que  agrupa  y  ordena  el  con¬ 
junto  de  tareas  o  actividades  destinadas  a  obtener  unos  objetivos. 
Esto  incluye  la  planificación,  definición,  ordenamiento  y  gestión  de 
las  actividades  que  formarán  el  proyecto  software. 

En  su  primera  expresión,  la  buena  gestión  de  un  proyecto  es  la  que 
es  capaz  de  reducir  al  mínimo  las  posibilidades  de  fallo  de  éste  du¬ 
rante  todo  el  transcurso  del  mismo.  Pudiendo  entenderse  como  fallo, 
la  no  consecución  de  los  requisitos  iniciales  del  proyecto,  la  inviabi¬ 
lidad  económica  del  mismo,  un  resultado  que  impida  mantenerlo  o 
le  impida  evolucionar,  etc. 
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Otra  visión  más  orientada  al  ámbito  de  costes  y  económico  del  proyecto 
es  la  que  define  la  buena  gestión  como  la  que  optimiza  el  uso  de  los  re¬ 
cursos  (tiempo,  dinero,  personas,  equipos,  etc.)  en  cada  fase  del  mismo. 

Muy  comúnmente,  la  gestión  del  proyecto  se  lleva  a  cabo  por  el  di¬ 
rector  del  proyecto,  normalmente  una  sola  persona  que  no  tiene  por 
qué  participar  activamente  en  las  actividades  del  mismo,  pero  que 
sí  que  se  ocupa  de  monitorizar  su  progreso  y  de  la  interacción  entre 
los  diferentes  grupos  que  intervienen  en  éste  para  minimizar  el  ries¬ 
go  de  fallo  del  proyecto. 

Además  de  hojas  de  cálculo  de  control  de  horas  por  tarea,  uso  de 
recursos,  etc.,  los  diagramas  de  Gantt  son  muy  usados  en  estos  en¬ 
tornos  por  mostrar  de  una  forma  clara  la  sucesión  de  tareas,  recur¬ 
sos  involucrados  y  sus  dependencias. 


Figura  1 .  Captura  de  pantalla  del  software  GPL  Imendio 
Planner  mostrando  un  diagrama  de  Gantt 


En  los  diagramas  de  Gantt,  representamos  las  actividades  que  hay  que 
realizar  en  forma  de  árbol  (mitad  izquierda  de  la  figura),  indicando  su 
fecha  de  inicio  y  su  duración  estimada.  El  programa  representa  la  acti¬ 
vidad  sobre  un  calendario  (mitad  derecha  de  la  figura)  y  nos  permite  de¬ 
finir  las  dependencias  entre  las  actividades.  Al  indicar  que  una  tarea 
debe  empezarse  al  terminar  otra,  o  que  deben  empezar  a  la  vez  o  ter¬ 
minar  las  dos  simultáneamente,  el  diagrama  va  modificando  automáti¬ 
camente  la  situación  de  las  actividades  en  el  tiempo. 
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Nota 


El  camino  crítico  de  un  pro¬ 
yecto  se  define  como  la  se¬ 
cuencia  de  tareas  que 
suman  el  intervalo  de  tiem¬ 
po  más  largo  del  mismo. 
Así  pues,  determina  la  dura¬ 
ción  mínima  del  proyecto, 
ya  que  un  retraso  en  alguna 
de  sus  tareas  tiene  un  im¬ 
pacto  directo  en  su  duración 
total. 


Dependiendo  de  la  complejidad  del  programa  que  utilicemos  para 
representar  el  diagrama,  podremos  especificar  también  los  recursos 
disponibles,  los  necesarios  para  cada  tarea,  etc.  y  seremos  capaces  de 
detectar  conflictos  en  la  planificación,  como  intervalos  en  los  que  no 
dispondremos  de  los  recursos  necesarios,  o  cuál  va  a  ser  el  camino  crí¬ 
tico  del  proyecto  (la  sucesión  de  tareas  que  por  sus  dependencias  van 
a  determinar  la  duración  máxima  del  proyecto). 

Concretamente,  en  entornos  de  software  libre,  no  existe  una  forma 
"tradicional"  de  gestionar  un  proyecto.  Un  buen  ejemplo  de  ello  es 
el  artículo  de  Eric  S.  Raymond,  "La  Catedral  y  el  Bazar",  en  el  que  se 
describe  la  forma  tradicional  de  gestionar  un  proyecto  como  analo¬ 
gía  de  construir  una  catedral,  y  se  compara  la  forma  como  se  ges¬ 
tionan  muchos  proyectos  de  software  libre  al  funcionamiento  de  un 
bazar. 


Web 


http://www.bugzilla.org/ 

http://sourceforge.net/ 


Proyectos  grandes  de  software  libre,  como  el  desarrollo  del  núcleo  Li¬ 
nux  o  el  servidor  web  Apache,  están  formados  por  un  comité  de  ges¬ 
tión  del  proyecto  (o  una  sola  persona  como  dictador  benevolente) 
que  deciden  los  siguientes  pasos  que  habrá  que  llevar  a  cabo  en  el 
proyecto,  y  que  inmediatamente  delegan  en  otras  personas  o  equi¬ 
pos  los  cambios  que  hay  que  realizar  para  llegar  a  los  objetivos.  La 
aprobación  de  los  cambios  realizados  o  bien  la  incorporación  de 
nuevas  funcionalidades  propuestas  por  los  usuarios  u  otros  desarro¬ 
lladores  sigue  el  proceso  inverso  hasta  llegar  al  comité  de  aproba¬ 
ción  que  decide  si  se  incorporan  al  proyecto  o  no. 

Por  supuesto,  en  este  tipo  de  gestión  de  proyectos,  juega  un  papel 
fundamental  las  herramientas  de  soporte  y  comunicación  entre  los 
diferentes  equipos.  Programas  de  gestión  de  incidencias  como  el  co¬ 
nocido  Bugzilla  o  entornos  como  Sourceforge  que  ayudan  a  los  ges¬ 
tores  del  proyecto  o  a  los  comités  organizadores  a  conocer  el  estado 
del  proyecto,  la  opinión  de  sus  usuarios,  las  aportaciones  de  los  de¬ 
sarrolladores,  etc. 


Proyectos  pequeños  o  medianos  de  software  libre  no  acostumbran  a 
seguir  una  metodología  tradicional,  y  se  orientan  más  a  una  gestión 
ágil  del  proyecto,  siguiendo  principios  acordes  con  el  software  libre, 
primando  la  publicación  de  nuevas  funcionalidades  y  versiones  del 
proyecto  al  cumplimiento  de  un  calendario  rígido  de  actividades  e  hitos. 
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En  estos  proyectos,  el  director  del  mismo  suele  intervenir  muy  estre¬ 
chamente  en  el  desarrollo  y  en  el  resto  de  actividades. 

Este  último  tipo  de  proyectos  suelen  gestionarse  mediante  simples  lis¬ 
tas  de  requisitos  y  fallos  por  resolver,  que  por  la  naturaleza  distribui¬ 
da  de  los  proyectos  de  software  libre,  deberá  estar  disponible  para 
su  consulta  y  modificación  por  parte  de  los  desarrolladores  y  usua¬ 
rios.  El  gestor  o  los  desarrolladores  serán  los  que  den  prioridad  a  las 
tareas,  y  decidan  cuáles  van  a  incorporar  en  las  nuevas  reteases  del 
proyecto. 


1 .4.2.  Ciclo  de  vida  del  software 

Se  llama  ciclo  de  vida  del  software  a  las  fases  por  las  que  pasa  un  pro¬ 
yecto  software  desde  que  es  concebido,  hasta  que  está  listo  para  usarse. 
Típicamente,  incluye  las  siguientes  actividades:  toma  de  requisitos,  aná¬ 
lisis,  diseño,  desarrollo,  pruebas  (validación,  aseguramiento  de  la  cali¬ 
dad),  instalación  (implantación),  uso,  mantenimiento  y  obsolescencia. 


El  proyecto  tiende  a  pasar  iterativamente  por  estas  fases,  en  lugar  de 
hacerlo  de  forma  lineal.  Así  pues,  se  han  propuesto  varios  modelos 
(en  cascada,  incremental,  evolutivo,  en  espiral,  o  concurrente,  por  ci¬ 
tar  algunos)  para  describir  el  progreso  real  del  proyecto. 
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El  modelo  en  cascada  es  el  más  simple  de  todos  ellos  y  sirve  de  base 
para  el  resto.  Simplemente  asigna  unas  actividades  a  cada  fase,  que 
servirán  para  completarla  y  para  proporcionar  los  requisitos  de  la  si¬ 
guiente.  Así,  el  proyecto  no  se  diseña  hasta  que  ha  sido  analizado,  o 
se  desarrolla  hasta  que  ha  sido  diseñado,  o  se  prueba  hasta  que  ha 
sido  desarrollado,  etc. 


Los  modelos  incremental  y  evolutivo  son  una  variación  del  modelo  en 
cascada  en  la  que  éste  se  aplica  a  subconjuntos  del  proyecto.  Depen¬ 
diendo  de  si  los  subconjuntos  son  partes  del  total  (modelo  incremental) 
o  bien  versiones  completas  pero  con  menos  prestaciones  (modelo  evo¬ 
lutivo)  estaremos  aplicando  uno  u  otro. 


El  modelo  en  espiral  se  basa  en  la  creación  de  prototipos  del  proyec¬ 
to,  que  pasan  por  las  fases  anteriores,  y  que  van  acercándose  suce¬ 
sivamente  a  los  objetivos  finales.  Así  pues,  nos  permite  examinar  y 
validar  repetidamente  los  requisitos  y  diseños  del  proyecto  antes  de 
acometer  nuevas  fases  de  desarrollo. 
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Finalmente,  el  modelo  iterativo  o  incremental  es  el  que  permite  que 
las  fases  de  análisis,  diseño,  desarrollo  y  pruebas  se  retroalimenten 
continuamente,  y  que  empiecen  lo  antes  posible.  Permitirá  atender  a 
posibles  cambios  en  las  necesidades  del  usuario  o  a  nuevas  herra¬ 
mientas  o  componentes  que  los  desarrolladores  descubran  y  que  fa¬ 
ciliten  el  diseño  o  proporcionen  nuevas  funcionalidades. 
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Se  trata  de  obtener  lo  más  rápidamente  una  versión  funcional  del 
software,  y  añadirle  prestaciones  a  partir  de  lo  que  se  ha  aprendido 
en  la  versión  anterior.  El  aprendizaje  proviene  tanto  del  desarrollo 
anterior,  como  del  uso  del  software,  si  es  posible.  En  este  tipo  de  de¬ 
sarrollo  es  imprescindible  establecer  una  lista  de  control  del  proyec¬ 
to,  donde  iremos  registrando  las  funcionalidades  que  faltan  por 
implementar,  las  reacciones  de  los  usuarios,  etc.  y  que  nos  propor¬ 
cionará  las  bases  para  cada  nueva  iteración. 

Este  último  método  es  el  más  usado  (aunque  sea  involuntaria¬ 
mente)  en  proyectos  de  software  libre,  por  la  propia  naturaleza 
cambiante  de  los  requisitos  o  la  aportación  constante  de  nuevos 
colaboradores. 


1 .4.3.  Análisis  de  requisitos 

El  análisis  de  requisitos  es  la  primera  fase  de  la  vida  de  un  proyecto. 
En  ella,  habrá  que  recoger  tanto  las  necesidades  del  usuario  del 
producto,  al  más  alto  nivel,  como  la  especificación  de  los  requisitos 
software  del  sistema. 

Para  guiarnos  en  ese  proceso,  existen  multitud  de  plantillas,  libros  y 
metodologías  orientados  a  extraer  del  usuario  (o  cliente)  lo  que  real¬ 
mente  quiere  que  haga  el  sistema.  Sin  duda,  no  es  una  tarea  sencilla. 
El  proyecto  ReadySET  hospedado  en  http://www.tigris.org  proporciona 
un  conjunto  de  plantillas  de  documentos  para  la  gestión  de  un  proyec¬ 
to  de  desarrollo  software,  extremadamente  útil  y  de  código  abierto. 

Siguiendo  estas  plantillas,  vemos  que  la  especificación  de  requisitos 
del  sistema  incluye,  como  mínimo: 

•  Los  casos  de  uso:  actores  que  intervendrán  en  el  uso  del  producto 
y  sus  posibles  acciones. 

•  Sus  requisitos  funcionales:  prestaciones  del  producto  en  la  prime¬ 
ra  versión  y  posible  planificación  para  las  futuras  versiones. 

•  Sus  requisitos  no  funcionales:  de  rendimiento,  de  usabilidad,  de 
seguridad,  etc. 
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En  entornos  de  software  libre,  muy  frecuentemente  el  fundador  (y 
gestor)  del  proyecto  será  también  su  primer  usuario,  pero  esto  no  le 
exime  de  esta  tarea,  que  determinará  el  alcance  del  proyecto  al  me¬ 
nos  en  sus  primeras  versiones,  y  permitirá  a  los  desarrolladores  que 
se  vayan  incorporando  al  proyecto,  hacerse  una  idea  de  su  progreso 
y  objetivos,  así  como  dónde  prestar  su  ayuda. 


1 .4.4.  Estimación  de  costes 

La  estimación  de  costes  (recursos,  equipos  y  tiempo  empleado)  es 
una  de  las  razones  de  ser  de  la  ingeniería  del  software.  Aunque  no 
siempre  aplicable  en  entornos  de  software  libre,  donde  no  suele  ser 
posible  realizar  una  planificación  de  recursos  disponibles,  es  conve¬ 
niente  conocer  las  métricas  y  métodos  que  nos  permitirán  predecir  el 
esfuerzo  que  supondrá  implementar  un  sistema  o  alguna  de  sus 
prestaciones. 

La  estimación  suele  realizarse  basándose  en  modelos  matemáticos 
que  parten  del  "tamaño"  estimado  del  proyecto,  y  de  constantes  que 
lo  ajustan  según  las  tecnologías  usadas,  recursos  de  que  disponemos, 
etc.  Los  modelos  nos  permiten  estimar  el  esfuerzo  requerido  (habitual¬ 
mente  en  horas/hombre  o  meses/hombre)  para  terminar  el  proyecto. 

Obviamente,  la  clave  está  en  estimar  el  "tamaño"  del  proyecto.  Aun 
sabiendo  lo  poco  indicativo  que  puede  llegar  a  ser,  son  bastantes  los 
modelos  que  usan  las  líneas  de  código  para  determinar  el  tamaño 
de  un  proyecto  (COCOMO,  COCOMO  II).  Otros  modelos  usan  los 
denominados  "puntos  de  función",  que  son  una  medida  de  la  com¬ 
plejidad  de  cada  funcionalidad  a  partir  de  las  entradas  que  recibe, 
las  salidas  que  aporta,  su  interacción  con  otras  funcionalidades  o  re¬ 
cursos,  etc. 

Existen  también  métricas  para  lenguajes  orientados  a  objetos,  que 
tienen  en  cuenta  factores  como  los  métodos  por  clase,  las  herencias 
entre  objetos,  la  interacción  entre  ellos,  su  grado  de  dependencia 
(que  complica  el  mantenimiento,  etc.). 


No  es  el  objetivo  de  este  capítulo  ahondar  en  estos  conceptos,  que 
requerirían  muchas  páginas  de  fórmulas,  tablas,  así  como  casos  de 
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éxito  o  fracaso  en  la  estimación.  El  estudiante  interesado  en  profun¬ 
dizar  encontrará  mucha  información  sobre  ellos  en  la  bibliografía. 


1 .4.5.  Diseño 

La  fase  de  diseño  del  sistema  producirá  un  conjunto  de  documentos 
que  describirán  un  sistema  que  cumpla  con  los  objetivos  de  la  fase  de 
análisis  de  requisitos.  Las  decisiones  que  se  tomen  en  esta  fase  debe¬ 
rán  basarse  en  esos  requisitos  y  en  la  comprensión  de  la  tecnología  y 
los  componentes  disponibles. 

Debe  tenerse  en  cuenta  que  muchos  de  los  documentos  que  se  crea¬ 
rán  en  esta  fase  van  a  usarse  por  los  desarrolladores  del  proyecto 
(diagramas  de  componentes  del  sistema,  arquitectura  del  mismo, 
etc.).  Esto  implica  que  deben  hacerse  lo  más  completos  posible,  y 
que  la  participación  de  los  desarrolladores  en  esta  fase  ayudará  a 
evitar  revisiones  innecesarias. 

Otros  documentos  irán  destinados  a  los  usuarios  del  proyecto  (p.  e¡., 
el  diseño  de  la  interfaz  de  usuario),  y  su  aprobación  y  entendimiento 
de  éstos  también  será  clave  para  evitar  desviaciones. 

Por  todo  ello,  es  muy  conveniente  disponer  de  listas  que  nos  permi¬ 
tan  comprobar  que  no  hemos  olvidado  ningún  aspecto  clave  en  esta 
fase.  El  proyecto  ReadySET  dispone  de  plantillas  de  casi  todos  los  do¬ 
cumentos  que  podemos  necesitar,  con  los  cuestionarios  correspon¬ 
dientes  y  ejemplos. 

Extrayendo  lo  más  significativo,  encontramos: 

•  Diagrama  estructural:  diseño  y  notas  sobre  la  estructura  del  siste¬ 
ma  en  detalle. 

•  Diagrama  de  comportamiento:  diseño  y  notas  sobre  el  compor¬ 
tamiento  del  sistema. 

•  Arquitectura  del  sistema:  diseño  de  sus  componentes,  de  su  im¬ 
plantación  e  integración. 
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•  Organización  de  código  fuente  y  compilación:  Directorios,  opcio¬ 
nes  de  compilación,  sistemas  de  control  de  versiones,  etc. 

•  Interfaz  de  usuario:  metáforas,  estándares  a  seguir,  diseño  de  los 
contextos  de  interacción  con  el  usuario,  etc. 

•  Sistema  de  información:  bases  de  datos,  abstracción  de  objetos, 
almacenamiento,  persistencia,  etc. 

•  Seguridad. 


1 .4.6.  Documentación 

La  documentación  de  un  proyecto  es  de  vital  importancia  para  su  éxi¬ 
to.  Ya  desde  la  fase  de  diseño,  como  parte  de  la  propia  arquitectura 
del  proyecto,  deberemos  definir  y  escoger  el  sistema  de  documenta¬ 
ción  que  usaremos  para  el  proyecto,  teniendo  en  cuenta  factores 
como  los  siguientes: 

•  Formatos  de  los  documentos,  según  su  tipología  y  métodos  de  ac¬ 
ceso.  Deberemos  definir  los  formatos  y  plantillas  elegidos  para  los 
diagramas  de  diseño,  hojas  de  cálculo,  hojas  de  seguimiento  del 
proyecto,  documentos  que  registren  fallos  o  cambios  en  las  espe¬ 
cificaciones  durante  el  desarrollo,  documentos  que  definan  la  in¬ 
terfaz  de  usuario,  etc. 

•  Método  de  acceso  y  flujo  de  trabajo  de  cada  tipo  de  documento. 
Quién  va  a  tener  acceso  a  los  diferentes  tipos  de  documentos  y 
bajo  qué  privilegios.  Dónde  se  van  a  notificar  los  cambios  que  se 
realicen  (¿en  el  propio  documento?,  ¿en  un  sistema  de  control  de 
versiones?). 

En  el  caso  de  la  documentación  del  propio  desarrollo  (del  código 
fuente  del  proyecto),  conviene  estudiar  las  herramientas  que  nos 
ofrezca  el  propio  lenguaje  para  generar  la  documentación,  ya  que 
en  muchos  casos  existen  herramientas  de  generación  de  documen¬ 
tación  a  partir  del  código  fuente  y  comentarios  insertados  mediante 
una  sintaxis  determinada  que  van  a  ayudar  mucho  en  el  proceso.  En 
el  capítulo  7  se  examinan  ejemplos  de  herramientas  de  este  tipo. 
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En  el  momento  de  tomar  decisiones  de  formato  y  flujos  de  trabajo 
sobre  la  documentación,  es  de  vital  importancia  tener  en  cuenta  los 
estándares  de  formatos  de  documento  existentes,  evitando  los  for¬ 
matos  propietarios  sobre  todo  en  organizaciones  heterogéneas  don¬ 
de  convivan  distintos  sistemas  operativos  o  en  proyectos  de  software 
libre,  para  dar  a  la  documentación  la  mayor  accesibilidad  posible. 
Suele  ser  una  buena  decisión  escoger  un  formato  de  documentación 
fácilmente  convertible  a  otros  (p.ej.,  XML)  y  así  poder  disponer  de  la 
documentación  en  HTML  para  su  consulta  rápida,  en  PDF  para  agre¬ 
gar  a  la  documentación  del  proyecto,  etc. 


1.4.7.  Pruebas  v  calidad 

La  planificación  de  prototipos,  pruebas  y  tests  para  el  aseguramiento 
de  la  calidad  es  también  un  tema  muy  tratado  en  la  ingeniería  del 
software. 

Para  que  un  proyecto  software  tenga  éxito,  es  necesario  que  el  resul¬ 
tado  cuente  con  la  calidad  esperada  por  el  cliente  o  los  usuarios.  Así 
pues,  la  calidad  del  proyecto  deberá  poderse  definir  en  términos  de 
prestaciones,  respuestas  esperadas  a  determinadas  acciones,  o  ac¬ 
cesibilidad  del  producto  en  diferentes  condiciones  para  poder  pro¬ 
barla  posteriormente  mediante  unos  tests  de  calidad  específicos. 

Deberá  ser  posible  realizar  un  plan  de  pruebas  o  de  aseguramiento 
de  la  calidad  que  clasifique  las  actividades  relacionadas  con  la  cali¬ 
dad  del  producto  según  su  importancia,  y  que  defina  con  qué  fre¬ 
cuencia  y  qué  resultados  se  deberían  obtener  de  cada  una  para 
pasar  a  la  siguiente  o  para  cumplir  los  requisitos  para  esa  release  en 
particular. 

El  proceso  de  aseguramiento  de  la  calidad  no  trata  únicamente  de 
que  el  producto  pase  todos  los  tests  establecidos,  sino  que  implicará 
en  muchos  casos  aspectos  como: 

•  El  uso  de  hojas  de  estilo  aprobadas  por  los  usuarios. 

•  La  confección  y  repaso  de  checklists  sobre  funcionalidades. 

•  La  revisión  periódica  del  producto  con  los  usuarios. 
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•  Las  herramientas  que  pondremos  a  disposición  de  los  usuarios 
para  comunicar  los  errores  o  sugerencias. 

•  El  uso  de  herramientas  de  análisis  para  medir  la  respuesta  del 
proyecto  a  determinadas  situaciones,  o  para  simular  un  uso  nor¬ 
mal  del  mismo. 

Los  modelos  tradicionales  de  ciclo  de  vida  del  software  incluían  la  fase 
de  pruebas  como  un  proceso  que  había  que  llevar  a  cabo  una  vez  fina¬ 
lizado  el  desarrollo.  Esto  se  ha  probado  que  resulta  altamente  contra¬ 
producente,  no  sólo  por  el  coste  de  arreglar  fallos  o  deficiencias  una  vez 
terminado  el  desarrollo,  sino  por  la  naturaleza  evolutiva  de  muchos  pro¬ 
yectos  (sobre  todo  en  entornos  de  software  libre),  en  los  que  la  fase  de 
desarrollo  no  termina  nunca  estrictamente  hablando. 

Así  pues,  se  tiende  a  incorporar  las  pruebas  (o  los  mecanismos  para 
llevarlas  a  cabo  de  modo  automatizado)  en  el  desarrollo  desde  el 
primer  momento.  Tecnologías  como  las  pruebas  unitarias  o  modelos 
como  el  pair-programming  o  el  peer-testing  nos  ayudarán  a  mante¬ 
ner  una  disciplina  en  el  desarrollo  y  a  aumentar  la  calidad  del  resul¬ 
tado  del  proyecto. 

Los  tipos  de  pruebas,  herramientas  de  gestión  de  las  mismas  y  los 
planes  de  calidad  se  tratan  en  detalle  en  el  capítulo  3. 


1 .4.8.  Seguridad 

La  seguridad  en  proyectos  software  ha  sido  un  factor  clave  desde  el 
inicio  de  la  ingeniería  del  software.  Igual  que  en  otros  conceptos 
como  la  calidad,  la  seguridad  no  puede  ser  un  módulo  en  el  diseño 
que  tiene  lugar  fuera  de  él,  ni  un  proceso  que  se  comprueba  al  fina¬ 
lizar  el  desarrollo,  sino  que  se  trata  de  un  aspecto  del  proyecto  que 
tiene  que  tenerse  en  cuenta  y  planificarse  desde  la  fase  de  diseño,  y 
que  afectará  a  lo  largo  de  todo  el  ciclo  de  vida  del  proyecto. 

Los  principios  básicos  de  la  seguridad  de  un  sistema  son  los  siguientes: 

•  Confidencialidad:  los  recursos  (o  funcionalidades  sobre  ellos)  son 
accesibles  sólo  para  los  usuarios  (o  procesos)  autorizados. 


•  Integridad:  los  recursos  pueden  ser  modificables  sólo  por  los 
usuarios  autorizados. 


•  Disponibilidad:  los  recursos  accesibles  están  disponibles. 


Muy  frecuentemente,  la  seguridad  de  un  proyecto  irá  más  allá  del 
mismo,  afectando  al  sistema  en  el  que  éste  se  va  a  implantar,  y  por 
lo  tanto  deberemos  asegurar  que  su  implantación  deja  al  sistema  fi¬ 
nal  en  un  estado  seguro. 


Es  por  esta  razón  por  lo  que,  en  la  fase  de  diseño  del  proyecto,  se 
debe  tener  en  cuenta  la  seguridad  del  mismo,  primero  de  forma  ge¬ 
neral  mediante  un  análisis  de  riesgos  y  de  actividades  destinadas  a 
mitigarlos,  y  más  adelante  mediante  la  ampliación  de  los  casos  de 
uso  según  los  principios  básicos  de  la  seguridad  comentados  ante¬ 
riormente. 


El  análisis  de  riesgos  consistirá,  de  forma  muy  resumida,  en  las  si¬ 
guientes  actividades: 


•  Recopilación  de  los  recursos  que  deben  ser  protegidos.  La  infor¬ 
mación,  todo  un  sistema,  un  sólo  dispositivo,  etc. 

•  Clasificación  de  los  actores  del  proyecto.  Cuáles  son  sus  casos  de 
uso  y  qué  roles  representan. 


•  Recopilación  de  requisitos  legales  y  de  negocio.  Certificaciones  que 
hay  que  cumplir,  restricciones  de  encriptación  por  exportación  a  de¬ 
terminados  países  o  bien  reglas  de  negocio  más  específicas  como  la 
aceptación  o  no  de  la  repudiación  por  parte  de  los  usuarios. 


•  Con  la  información  recopilada,  deberíamos  ser  capaces  de 
construir  una  tabla  en  la  que,  para  cada  riesgo,  estimáramos 
el  coste  que  tiene  por  incidente,  y  a  partir  de  una  estimación  de 
incidentes  por  año,  nos  permitiera  decidir  sobre  la  estrategia 
que  hay  que  implantar  (aceptar  el  riesgo  tal  como  es  y  definir 
un  plan  de  contingencia  en  caso  de  producirse,  o  bien  mitigarlo 
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mediante  desarrollos  adicionales,  otras  herramientas  o  cam¬ 
bios  en  el  diseño  que  lo  permitan). 


Figura  6 
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Sin  entrar  en  detalle,  enunciamos  a  continuación  un  conjunto  de 
buenas  prácticas  genéricas  que  ayudarán  a  mitigar  los  riesgos  aso¬ 
ciados  a  cualquier  proyecto: 


•  Asignar  el  mínimo  privilegio  posible  a  cada  actor  en  el  sistema. 


•  Simplicidad.  La  seguridad  por  ofuscación  no  da  buenos  resultados. 


•  Diseño  abierto.  Siempre  tendremos  alternativas  para  mejorar  o 
asegurar  más  el  sistema. 


•  Seguridad  por  defecto.  El  sistema  debe  ser  el  máximo  de  seguro 
por  defecto,  si  tiene  que  ser  posible  relajar  las  restricciones,  debe 
tratarse  de  una  acción  adicional  a  realizar  con  el  proyecto  ya  im¬ 
plantado. 


•  Fallada  segura.  Si  el  sistema  falla  o  puede  fallar,  evitar  que  lo 
haga  quedándose  en  una  modalidad  insegura. 


•  Minimizar  el  uso  de  recursos  compartidos. 


•  Trabajar  a  favor  de  la  usabilidad  del  proyecto  redunda  en  un  me¬ 
jor  uso  de  él  y  en  menores  probabilidades  de  fallos  de  seguridad 
por  un  mal  uso  del  mismo. 
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1.5.  Ejemplos  de  metodologías 


Hasta  ahora  hemos  hecho  un  breve  repaso  a  la  historia  y  los  con¬ 
ceptos  relacionados  con  la  ingeniería  del  software  en  general.  A 
continuación,  vamos  a  examinar  un  poco  más  detalladamente  dos 
metodologías  concretas  para  ver  cómo  intentan  resolver  algunos 
de  los  problemas  comentados,  y  poder,  así,  tomar  decisiones  en  la 
gestión  de  proyectos. 

Cabe  comentar  que  no  es  siempre  conveniente  escoger  y  aplicar  una 
metodología  de  forma  estricta.  Es  importante  entenderla  y  conocer 
qué  nos  puede  aportar  a  nuestro  proyecto,  para  aplicarla  en  esas  fa¬ 
ses  o  procesos  en  los  que  nuestro  equipo  o  nuestros  usuarios  estén 
más  cómodos  con  ella,  y  no  al  revés. 

En  entornos  de  software  libre,  no  es  habitual  que  los  programadores 
que  colaboran  de  forma  altruista  en  el  proyecto  quieran  hacerlo  bajo 
una  metodología  demasiado  estricta.  Sin  embargo,  valorarán  enor¬ 
memente  las  facilidades  de  gestión  que  ofrezca  el  proyecto,  el  acceso 
a  su  documentación,  la  calidad  de  la  misma,  etc.,  por  lo  que  estarán 
mucho  más  motivados,  y  pasarán  más  tiempo  colaborando  en  el 
proyecto  que  entendiéndolo.  De  la  misma  manera,  determinados  co¬ 
laboradores  o  clientes  rechazarán  una  metodología  demasiado  mo¬ 
derna  o  flexible  por  desconocimiento. 


1.5.1.  Metodología  próxima  al  software  libre: 
eXtreme  Programming 

eXtreme  Programming  o  programación  eXtrema,  es  una  de  las  meto¬ 
dologías  llamadas  "ágiles",  para  el  desarrollo  de  proyectos  de  software. 
Se  basa  en  los  principios  de  la  simplicidad,  la  comunicación,  la  re- 
troalimentación  y  el  coraje  para  implicar  a  todo  el  equipo  (y  a  los 
usuarios  o  clientes)  en  la  gestión  del  proyecto.  En  1  99ó,  Kent  Back  y 
Ward  Cunningham  pusieron  en  práctica  una  nueva  metodología 
primando  la  simplicidad  y  evitando  los  hábitos  que  convertían  las 
cosas  fáciles  en  difíciles  durante  el  desarrollo  de  un  proyecto  en 
DaimlerChrysIer.  El  resultado  fue  la  metodología  eXtreme  Programming 
o  XP  (que  por  supuesto  nada  tiene  que  ver  con  software  de  la  compañía 
Microsoft). 
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En  su  forma  más  genérica,  las  metodologías  ágiles  proponen  una  im¬ 
plicación  total  del  cliente  en  el  proyecto,  y  llevan  al  límite  el  modelo  de 
desarrollo  evolutivo  en  espiral.  Esto  es,  realizar  un  plan  de  proyecto 
basado  en  versiones  del  producto  acordadas  a  partir  de  funcionalida¬ 
des  concretas,  y  realizar  el  desarrollo  para  esas  funcionalidades  con¬ 
cretas.  Una  vez  entregada  la  versión  del  proyecto  cumpliendo  con  los 
requisitos  (no  un  prototipo,  sino  una  versión  funcionando),  el  proceso 
vuelve  a  iniciarse  con  un  conjunto  mayor  de  funcionalidades. 

Los  procesos  y  prácticas  de  esta  metodología  están  basados  en  la  ex¬ 
periencia  de  equipos  de  desarrollo,  y  en  los  errores  cometidos  o  en¬ 
contrados  una  y  otra  vez  al  utilizar  metodologías  más  tradicionales. 
Sin  embargo,  veremos  que  algunas  de  sus  propuestas  son  bastante 
chocantes  y  otras  serán  incompatibles  con  grandes  organizaciones  o 
grandes  proyectos. 

La  proximidad  de  esta  metodología  al  entorno  del  software  libre  viene 
dada  por  sus  principios  básicos,  más  que  por  su  aplicación  concreta. 
En  los  próximos  apartados  examinaremos  estos  principios  y  veremos 
que  algunos  están  muy  cercanos  al  software  libre,  mientras  que  otros 
(sobre  todo  los  que  tienen  que  ver  con  el  cliente,  o  con  la  programa¬ 
ción  en  pares)  no  suelen  ser  demasiado  aplicables. 

eXtreme  Programming,  puede  dividirse  en  cuatro  principios  sobre  los 
que  se  va  iterando  hasta  que  el  proyecto  ha  finalizado  (el  cliente  aprue¬ 
ba  el  proyecto).  Estas  fases  o  principios  son  planificación,  diseño,  de¬ 
sarrollo  y  pruebas.  Aunque  a  primera  vista  parece  que  no  estamos 
añadiendo  nada  nuevo  a  las  metodologías  tradicionales,  es  en  los  de¬ 
talles  de  cada  fase,  y  en  los  objetivos  que  nos  marcaremos  en  cada  una 
de  ellas  (iteración  tras  iteración)  donde  están  las  mayores  diferencias. 
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Planificación 


La  planificación  empieza  con  la  confección  de  las  "Historias  de  usua¬ 
rio".  De  manera  similar  a  los  casos  de  uso,  se  trata  de  breves  frases  es¬ 
critas  por  el  cliente  (no  más  de  tres  líneas),  en  las  que  se  describe  una 
prestación  o  un  proceso  sin  ningún  tipo  de  tecnicismo  (es  el  usuario  o 
el  cliente  quien  las  escribe). 

Estas  historias  de  usuario  servirán  para  realizar  la  planificación  de 
releases,  así  como  para  los  tests  de  aceptación  con  el  cliente.  Para 
cada  historia  deberíamos  poder  estimar  su  tiempo  ideal  de  desarro¬ 
llo,  que  debería  ser  de  1 , 2  o  3  semanas  como  máximo.  Si  el  tiempo 
de  desarrollo  es  mayor,  deberemos  partir  la  historia  en  trozos  que  no 
excedan  de  esas  estimaciones. 

A  continuación  podemos  pasar  a  la  propia  planificación  de  la  próxima 
(o  primera)  release  del  proyecto.  En  la  reunión  de  planificación  debe¬ 
remos  implicar  al  cliente,  al  gestor  del  proyecto  y  a  los  desarrolladores. 
El  objetivo  será  planificar  las  siguientes  releases  poniendo  en  orden  las 
historias  de  usuario  que  faltan  por  desarrollar.  Deberá  ser  el  cliente 
quien  dicte  el  orden  de  las  historias  de  usuario,  y  los  desarrollado¬ 
res  quienes  estimen  el  tiempo  que  les  llevaría  idealmente  en  desa¬ 
rrollarlo  (idealmente  aquí  significa  sin  tener  en  cuenta  dependencias, 
ni  otros  trabajos  o  proyectos,  pero  sí  incluyendo  las  pruebas). 

Las  historias  de  usuario  se  suelen  reflejar  en  tarjetas  o  trozos  de  papel, 
que  se  van  agrupando  y  clasificando  encima  de  la  mesa  durante  la  pla¬ 
nificación.  El  resultado  deberá  ser  un  conjunto  de  historias  que  tengan 
sentido,  y  que  puedan  llevarse  a  cabo  en  poco  tiempo.  Para  planificar¬ 
lo,  podemos  hacerlo  según  dos  criterios,  basándonos  en  el  tiempo  has¬ 
ta  la  siguiente  release  o  en  el  alcance  (entendido  como  el  número  de 
funcionalidades)  que  deseamos  que  tenga. 

Aquí  introducimos  un  nuevo  concepto,  la  velocidad  del  proyecto.  Esta 
velocidad  nos  servirá  para  decidir  cuántas  historias  de  usuario  va¬ 
mos  a  incluir  en  la  próxima  release  (si  estamos  planificando  en  base 
al  tiempo,  ya  fijado),  o  bien  cuando  vamos  a  tardar  en  lanzar  la 
release  (si  estamos  planificando  por  alcance,  ya  fijado).  La  velocidad 
del  proyecto  es  simplemente  el  número  de  historias  de  usuario  com¬ 
pletadas  en  la  iteración  anterior.  Si  se  trata  de  la  primera  iteración, 
habrá  que  hacer  una  estimación  inicial. 


La  velocidad  puede  aumentarse,  si  en  el  transcurso  del  desarrollo  se 
finalizan  las  historias  de  usuario  previstas  antes  de  tiempo.  Entonces 
los  desarrolladores  pedirán  historias  de  usuario  que  estaban  planea¬ 
das  para  la  siguiente  release.  Este  mecanismo  permite  a  los  desarro¬ 
lladores  recuperarse  en  los  periodos  duros,  para  después  acelerar  el 
desarrollo  si  es  posible.  Recordemos  que  las  historias  deben  tener  to¬ 
das  una  duración  máxima,  y  que  cuanto  más  parecido  sea  el  volu¬ 
men  de  trabajo  estimado  en  cada  una  de  ellas,  más  fiable  será  la 
medida  de  velocidad  del  desarrollo. 

Este  método  de  planificación  rápido  y  adaptativo  nos  permite  hacer 
un  par  de  iteraciones  para  tener  una  medida  fiable  de  lo  que  será  la 
velocidad  media  del  proyecto  y  estimar  así  más  detalladamente  el 
plan  de  releases  (además  de  haber  empezado  ya  con  el  desarrollo 
del  mismo)  en  el  intervalo  de  tiempo  en  que  otras  metodologías  tar¬ 
darían  en  documentar,  planificar  y  realizar  una  estimación  completa, 
que  quizá  no  sería  tan  fiable. 

En  la  reunión  de  planificación,  al  inicio  de  cada  iteración,  también 
habrá  que  incorporar  las  tareas  que  hayan  generado  los  tests  de 
aceptación  que  el  cliente  no  haya  aprobado.  Estas  tareas  se  sumarán 
también  a  la  velocidad  del  proyecto,  y  el  cliente,  que  es  quien  escoge 
las  historias  de  usuario  que  hay  que  desarrollar,  no  podrá  elegir  un 
número  mayor  que  el  de  la  velocidad  del  proyecto. 

Los  desarrolladores  convertirán  las  historias  de  usuario  en  tareas  (esas 
sí  en  lenguaje  técnico)  de  una  duración  máxima  de  tres  días  ideales  de 
programación  cada  una.  Se  escribirán  en  tarjetas  y  se  pondrán  enci¬ 
ma  de  la  mesa  para  agruparlas,  eliminar  las  repetidas,  y  asignarlas  a 
cada  programador.  Es  de  vital  importancia  evitar  añadir  más  funcio¬ 
nalidades  que  las  que  la  historia  de  usuario  estrictamente  requiera. 
Esta  tendencia  de  los  gestores  de  proyectos  o  analistas  acostumbrados 
a  las  metodologías  tradicionales  debe  evitarse  en  modelos  iterativos 
como  éste,  ya  que  desvirtúan  las  estimaciones  y  el  principio  de  releases 
frecuentes. 

Con  las  tareas  resultantes,  se  volverá  a  comprobar  que  no  estamos 
excediendo  la  velocidad  del  proyecto,  eliminando  o  añadiendo  his¬ 
torias  de  usuario  hasta  llegar  a  su  valor.  Es  posible  que  historias  de 
usuario  diferentes  tengan  tareas  en  común,  y  esta  fase  de  la  planifi¬ 
cación  nos  permitirá  filtrarlas,  para  así  poder  aumentar  la  velocidad 
del  proyecto  añadiendo  más  historias  de  usuario  en  esta  iteración. 
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En  el  momento  de  planificar  el  equipo  de  trabajo  encargado  de  cada 
tarea  o  historia,  es  importante  la  movilidad  de  las  personas,  intentar 
que  cada  dos  o  tres  iteraciones  todo  el  mundo  haya  trabajado  en  todas 
las  partes  del  sistema.  Conceptos  como  el  pair  programming,  que  vere¬ 
mos  en  siguientes  apartados,  también  pueden  ayudar. 


Diseño 

Durante  el  diseño  de  la  solución,  y  de  cada  historia  de  usuario  que 
lo  requiera,  la  máxima  simplicidad  posible  es  la  clave  para  el  éxito 
de  esta  metodología.  Sabiendo  que  un  diseño  complejo  siempre  tar¬ 
da  más  en  desarrollarse  que  uno  simple,  y  que  siempre  es  más  fácil 
añadir  complejidad  a  un  diseño  simple  que  quitarla  de  uno  comple¬ 
jo,  siempre  deberemos  hacer  las  cosas  lo  más  sencillas  posible,  evi¬ 
tando  añadir  funcionalidad  no  contemplada  en  esa  iteración. 

Asimismo,  es  importante  y  se  ha  probado  muy  útil  encontrar  una  me¬ 
táfora  para  definir  el  sistema.  Es  decir,  un  proceso  o  sistema  que  to¬ 
dos  conozcan  (el  cliente,  el  gestor  del  proyecto,  los  desarrolladores) 
y  que  puedan  identificar  con  el  proyecto  que  se  está  desarrollando. 
Encontrar  una  buena  metáfora  ayudará  a  tener: 

•  Visión  común:  todo  el  mundo  estará  de  acuerdo  en  reconocer  dónde 
está  el  núcleo  del  problema,  y  en  cómo  funciona  la  solución.  Nos 
ayudará  a  ver  cómo  será  el  sistema  o  qué  podría  llegar  a  ser. 

•  Vocabulario  compartido:  la  metáfora  nos  ayudará  a  sugerir  un  vo¬ 
cabulario  común  para  los  objetos  y  procesos  del  sistema.  Depen¬ 
diendo  de  la  metáfora  escogida,  el  vocabulario  puede  ser  altamente 
técnico  o  por  el  contrario  muy  común. 

•  Generalización:  la  metáfora  puede  sugerir  nuevas  ideas  o  solucio¬ 
nes.  Por  ejemplo,  en  la  metáfora  "el  servicio  de  atención  al  cliente  es 
una  cadena  de  montaje",  nos  sugiere  que  el  problema  va  pasando 
de  grupo  en  grupo  de  gente.  Pero  también  nos  hace  pensar  en  qué 
pasa  cuando  el  problema  llega  al  final  de  la  cadena... 

•  Arquitectura:  la  metáfora  dará  forma  al  sistema,  nos  identificará 
los  objetos  clave  y  nos  sugerirá  características  de  sus  interfaces. 
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Para  el  diseño  del  sistema,  se  sugiere  llevar  a  cabo  reuniones  entre  to¬ 
dos  los  desarrolladores  implicados,  donde  se  toman  las  decisiones  me¬ 
diante  el  uso  de  tarjetas  CRC  (c/ass,  responsabilices  y  collaboration). 
Cada  tarjeta  representa  un  objeto  del  sistema,  en  la  que  su  nombre 
aparece  escrito  en  la  parte  superior,  sus  responsabilidades  en  la  parte 
izquierda  y  los  objetos  con  los  que  colabora  en  la  parte  derecha. 


El  proceso  de  diseño  se  realiza  creando  las  tarjetas  (al  inicio  sólo  es¬ 
cribiremos  el  nombre  en  ellas,  el  resto  ya  se  irá  completando)  y  si¬ 
tuándolas  próximas  a  las  que  comparten  interfaces  o  llamadas.  Las 
tarjetas  correspondientes  a  objetos  que  heredan  o  son  interfaces  de 
otros  pueden  situarse  encima  o  debajo. 

Este  mecanismo  ayuda  a  que  todo  el  mundo  participe  y  aporte  sus 
ideas  en  el  diseño  moviendo  las  tarjetas  encima  de  la  mesa  según 
éste  va  progresando.  Si  se  llega  a  un  punto  muerto  y  se  decide  volver 
a  empezar,  será  tan  simple  como  "limpiar"  la  mesa  y  volver  a  ir  si¬ 
tuando  las  tarjetas.  No  tendremos  que  borrar  diagramas  ni  hacer 
trabajo  extra  diseñando  alternativas.  Cuando  tengamos  el  diseño 
definitivo,  también  será  más  fácil  de  mantener  en  la  memoria  por 
parte  de  los  participantes  y  es  entonces  cuando  entraremos  en  deta¬ 
lle  en  cada  objeto  y  haremos  los  diagramas  necesarios. 

Finalmente,  es  clave  también  el  concepto  de  refactorización,  es  decir, 
el  hecho  de  realizar  cambios  necesarios  en  las  partes  de  código  que 
lo  requieran,  sin  modificar  su  funcionalidad  o  su  interacción  con  el 
resto  del  sistema.  A  medida  que  vayamos  avanzando  en  iteraciones 
en  el  proyecto,  nos  veremos  obligados  a  modificar  o  ampliar  partes 
de  código  ya  escritas  anteriormente.  En  ese  momento,  en  lugar  de 
dejar  lo  que  funcionaba  sin  tocarlo  y  desarrollar  el  módulo  adicio¬ 
nal  para  la  nueva  funcionalidad,  deberemos  hacer  el  esfuerzo  de 
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refactorizar  el  módulo  existente,  dejándolo  igual  de  simple  pero  con 
la  nueva  funcionalidad  añadida.  Será  siempre  mucho  más  fácil  de 
probar,  de  explicar  y  de  comprender  para  el  resto  del  equipo. 

Este  concepto,  provocará  cambios  en  el  diseño  que  habíamos  hecho 
en  iteraciones  anteriores,  pero  esto  no  es  perjudicial,  sino  al  contra¬ 
rio.  Deberemos  darnos  cuenta  de  que  el  diseño  evoluciona  iteración 
tras  iteración,  por  lo  que  el  diseño  anterior  ya  estará  obsoleto  a  partir 
de  ese  momento,  y  acostumbrarnos  a  ello. 


Codificación 

Una  primera  diferencia  importante  entre  esta  metodología  y  las  lla¬ 
madas  "tradicionales"  es  la  disponibilidad  del  cliente,  que  debe  ser 
total.  En  lugar  de  limitarse  a  escribir  durante  semanas  una  hoja  de 
requisitos,  el  cliente  debe  participar  en  las  reuniones  de  planifica¬ 
ción,  tomar  decisiones,  y  estar  disponible  para  los  desarrolladores 
durante  los  tests  funcionales  y  de  aceptación. 

Debido  a  la  movilidad  de  los  desarrolladores  durante  el  proyecto, 
participando  en  cada  iteración  en  partes  distintas  del  mismo,  es  de 
vital  importancia  acordar  unos  estándares  de  codificación  y  respetar¬ 
los  en  el  desarrollo.  Cada  lenguaje  de  programación  tiene  sugeren¬ 
cias  o  reglas  más  o  menos  detalladas  al  respecto.  Deberemos  ser  tan 
concretos  como  sea  posible,  no  dejando  al  libre  albedrío  temas 
como  la  indentación  en  el  código,  la  sintaxis  y  nombres  de  variables, 
etc.  En  casi  todos  los  casos  existen  unas  convenciones  recomendadas 
por  los  creadores  del  lenguaje  que  cubren  estos  aspectos. 

Siempre  es  conveniente  tener  en  cuenta  estas  recomendaciones  y  uti¬ 
lizarlas  tal  cual  o  bien  adaptarlas  a  las  preferencias  de  nuestros  pro¬ 
gramadores,  pero  en  cualquier  caso  es  imprescindible  definir  las 
decisiones  tomadas  al  respecto. 

Por  lo  que  respecta  a  la  propia  codificación  en  sí,  eXtreme  Program- 
ming  nos  propone  que  antepongamos  la  creación  de  los  tests  unita¬ 
rios  al  propio  desarrollo  de  las  funcionalidades.  Los  tests  unitarios  se 
explicarán  con  detalle  en  el  capítulo  correspondiente,  pero  básica¬ 
mente  son  pequeños  trozos  de  código  que  prueban  las  funcionalida¬ 
des  de  un  objeto,  de  modo  que  esa  prueba  pueda  incorporarse  a  un 
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proceso  de  pruebas  automatizado.  La  mayoría  de  los  lenguajes  tie¬ 
nen  hoy  en  día  librerías  para  crear  y  ejecutar  pruebas  unitarias. 

La  idea  que  se  fragua  detrás  de  esta  propuesta  es  que  creando  pri¬ 
mero  las  pruebas  que  deberá  pasar  nuestro  código,  tendremos  una 
idea  más  clara  de  lo  que  deberemos  codificar,  y  nos  guiaremos  por 
ello,  implementando  únicamente  lo  que  nos  permita  pasar  la  prue¬ 
ba.  También  tendremos  ventajas  adicionales  al  conocer  cuándo  he¬ 
mos  acabado  de  implementar  la  funcionalidad  requerida,  o  en  la 
comprensión  de  la  misma. 

Otra  característica  diferencial  de  eXtreme  Programming  es  el  pair  pro- 
gramming  o  la  programación  por  parejas.  Se  ha  demostrado  que  dos 
programadores,  trabajando  conjuntamente,  lo  hacen  al  mismo  ritmo 
que  cada  uno  por  su  lado,  pero  el  resultado  obtenido  es  de  mucha 
más  calidad.  Simplemente  los  dos  sentados  frente  al  mismo  monitor, 
y  pasándose  el  teclado  cada  cierto  tiempo,  provoca  que  mientras  uno 
está  concentrado  en  el  método  que  está  codificando,  el  otro  piense  en 
cómo  ese  método  va  a  afectar  al  resto  de  objetos  y  la  interacción,  las 
dudas  y  propuestas  que  surgen  reducen  considerablemente  el  número 
de  errores  y  los  problemas  de  integración  posteriores. 

En  una  metodología  incremental  como  ésta,  la  integración  con  lo 
que  ya  se  ha  desarrollado  en  iteraciones  anteriores  es  clave.  No  hay 
una  única  solución  a  ese  problema.  Dependiendo  del  proyecto  y  del 
equipo  de  trabajo,  se  pueden  proponer  soluciones,  como  por  ejem¬ 
plo  designar  "dueños"  para  cada  objeto,  que  conozcan  todos  los 
tests  unitarios  y  de  integración  que  debe  pasar,  y  se  ocupe  de  inte¬ 
grarlo  en  cada  release.  Otra  alternativa  es  que  cada  pareja  de  pro¬ 
gramadores  se  hace  responsable  de  integrar  cuando  todos  los  tests 
de  la  tarea  que  estaban  realizando  pasan  al  100%.  De  este  modo, 
añadimos  al  paradigma  release-often  (distribuye  o  implanta  a  menu¬ 
do)  el  integrate-often  (integra  a  menudo),  reduciendo  enormemente 
las  posibilidades  de  problemas  de  integración. 


Pruebas 

Ya  hemos  hablado  sobre  las  pruebas  unitarias  en  la  fase  anterior,  y 
se  verán  en  detalle  en  el  apartado  correspondiente.  Es  importante 
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insistir  en  este  tema,  ya  que,  aun  en  el  caso  de  tener  una  fecha  de 
entrega  muy  próxima,  la  construcción  de  las  pruebas  unitarias  va  a 
ahorrarnos  mucho  más  tiempo  del  que  invertimos  programándolas, 
buscando  pequeños  fallos  y  protegiéndonos  contra  ellos  de  forma 
permanente  durante  el  resto  del  desarrollo. 

Cuanto  más  complicada  sea  la  prueba,  más  necesaria  es  para  ase¬ 
gurar  que  después  el  desarrollo  hace  lo  que  se  requiere. 

A  veces  existe  la  tendencia  a  pensar  que  las  pruebas  unitarias  pue¬ 
den  hacerse  durante  los  últimos  tres  meses  de  desarrollo.  Esto  es 
erróneo,  ya  que  sin  esas  pruebas,  el  desarrollo  se  alarga  esos  tres 
meses,  y  quizá  más. 

Los  tests  unitarios  ayudarán  también  a  la  refactorización,  ya  que  ase¬ 
gurarán  que  los  cambios  que  hayamos  introducido  en  la  iteración 
actual  no  afecten  a  la  funcionalidad. 

Cuando  encontremos  un  fallo  o  bug  en  los  tests  de  aceptación  con  el 
cliente,  o  durante  el  uso,  deberemos  crear  un  test  unitario  que  lo  com¬ 
pruebe.  Así  aseguramos  que  no  vuelve  a  surgir  en  siguientes  iteraciones. 

Los  tests  de  aceptación  se  crearán  a  partir  de  las  historias  de  usuario. 
Una  historia  puede  tener  uno  o  varios  tests,  según  sea  la  funcionali¬ 
dad  que  hay  que  probar.  El  cliente  es  responsable  de  definir  los  tests 
de  aceptación,  que  deberían  ser  automatizables  en  la  medida  de  lo 
posible.  Estos  test  son  del  tipo  "caja  negra",  en  el  sentido  de  que  úni¬ 
camente  nos  definen  el  resultado  que  debe  tener  el  sistema  ante  unas 
entradas  concretas.  Los  tests  de  aceptación  que  no  tengan  éxito  gene¬ 
rarán  nuevas  tareas  para  la  próxima  iteración,  afectando  así  a  la  velo¬ 
cidad  del  proyecto,  y  proporcionando  además  una  puntuación  del  éxito 
o  fracaso  de  cada  historia  de  usuario,  o  de  cada  equipo  de  trabajo. 


Conclusiones 

Hemos  visto  de  manera  rápida  e  introductoria  la  metodología  eXtreme 
Programing,  y  comentado  sus  particularidades  respecto  a  las  metodo¬ 
logías  tradicionales.  Sin  duda,  introduce  algunos  conceptos  novedosos 
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y  hasta  discutibles  como  el  pair-programming,  pero  también  usa  téc¬ 
nicas  más  convencionales  como  las  tarjetas  CRC. 

Prescindiendo  de  los  detalles,  lo  que  XP  propone  es  un  cambio  de  pa¬ 
radigma  a  lo  largo  de  toda  la  metodología.  Las  herramientas  concretas, 
como  las  pruebas  unitarias,  las  historias  de  usuario,  la  refactorización, 
etc.  no  son  más  que  recursos  que  también  podríamos  utilizar  en  otras 
metodologías.  Lo  verdaderamente  destacable  de  XP  es  su  forma  de  or¬ 
denar  el  ciclo  de  vida  del  proyecto,  y  la  involucración  con  el  cliente.  Sin 
esto,  no  estamos  haciendo  XP. 

Sus  principales  características  lo  hacen  muy  adecuado  para  proyectos 
de  software  libre,  aunque,  como  hemos  visto  en  su  breve  historia,  no  fue 
concebido  con  este  objetivo.  Otros  aspectos  como  el  pair-programming 
o  el  diseño  colaborativo  con  tarjetas  CRC  no  son  tan  aplicables  en  este 
ámbito. 


1.5.2.  Metodología  clásica:  Métrica  v3 

"Métrica  v3"  es  la  metodología  de  planificación,  desarrollo  y  mante¬ 
nimiento  de  sistemas  de  información  promovida  por  la  Secretaría  del 
Consejo  Superior  de  Informática  del  Ministerio  de  Administraciones 
Públicas,  que  es  el  órgano  interministerial  responsable  de  la  política 
en  informática  del  Gobierno  español. 

Aunque  su  ámbito  inicial  es  el  de  las  administraciones  públicas,  las 
mejoras  introducidas  en  la  versión  3  y  el  mejor  uso  de  estándares  y 
normas  de  ingeniería  del  software  hacen  que  su  alcance  pueda  am¬ 
pliarse  a  las  administraciones  autonómicas,  locales  y  al  resto  de  em¬ 
presas  y  organizaciones. 

Entre  las  mejoras  introducidas  en  la  versión  3.0  (publicada  en  el 
año  2000),  destaca  la  incorporación  de  nuevos  métodos  y  tecnolo¬ 
gías  (cliente/servidor,  interfaz  gráfica  de  usuario,  orientación  a  ob¬ 
jetos),  así  como  la  incorporación  de  aspectos  de  gestión  (que  la 
metodología  denomina  interfaces )  para  mejorar  aspectos  que  no  perte¬ 
necen  a  una  sola  fase,  sino  que  intervienen  a  lo  largo  del  proyecto, 
como  son  la  gestión  del  mismo,  la  calidad  y  la  seguridad,  entre  otros. 
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La  estructura  de  la  metodología  sigue  el  clásico  método  en  cascada 
basado  en  los  siguientes  procesos: 

•  Planificación 

•  Desarrollo 

•  Mantenimiento 

Cada  proceso  de  los  anteriores  detalla  las  actividades  y  tareas  que 
hay  que  realizar,  de  manera  que  para  cada  tarea  se  indican: 

•  Las  técnicas  y  prácticas  a  utilizar. 

•  Los  responsables  de  realizarla. 

•  Sus  productos  de  entrada  y  salida. 
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El  aspecto  más  destacable  de  esta  metodología  no  es  tanto  lo  que  pue¬ 
da  aportar  como  innovación  a  la  ingeniería  del  software  en  sí,  sino  el 
esfuerzo  que  se  ha  hecho  por  poner  a  disposición  pública  una  metodo¬ 
logía  completa,  más  o  menos  actualizada,  y  que  representa  un  marco 
inicial  de  referencia  para  presentar  proyectos  a  la  Administración  públi¬ 
ca  (que  lo  exigen  como  requisito),  pero  que  podemos  adaptar  a  nuestra 
empresa  o  proyecto  en  el  sector  privado,  si  nuestra  organización  se  sien¬ 
te  más  cómoda  con  modelos  clásicos  de  desarrollo. 

Métrica  v3  define  muy  bien  los  documentos  de  entrada  de  cada  pro¬ 
ceso,  actividad  y  tarea,  así  como  el  resultado  que  genera.  A  lo  largo 
de  éste  y  los  siguientes  apartados,  vamos  a  destacar  los  más  relevan¬ 
tes.  Si  se  desea  ampliar  información,  la  documentación  disponible  es 
muy  extensa,  y  existen  ejemplos,  cursos  de  autoformación,  así  como 
programas  auxiliares  de  ayuda  y  selección  de  herramientas  compa¬ 
tibles  con  la  metodología. 


Planificación  de  sistemas  de  información 

Este  proceso  tiene  como  objetivo  último  la  creación  del  Plan  de  siste¬ 
mas  de  información  (PSI)  de  la  organización.  Adaptando  el  marco  y 
los  objetivos,  podemos  utilizar  sus  actividades  para  generar  el  plan 
del  proyecto  en  concreto  en  el  que  estamos  trabajando. 

Entre  las  actividades  que  deberemos  realizar,  destacan: 

•  Descripción  de  la  situación  actual. 

•  Conjunto  de  modelos  que  constituye  la  arquitectura  de  la  infor¬ 
mación. 

•  Priorización  y  calendario  de  los  proyectos  a  desarrollar. 

•  Evaluación  de  los  recursos  necesarios. 

•  Plan  de  seguimiento  y  cumplimiento,  bajo  una  perspectiva  estra¬ 
tégica  y  operativa. 

El  plan  debe  ser  realizado  a  alto  nivel,  sin  tecnicismos  y  con  una  pers¬ 
pectiva  estratégica  y  operativa.  Asimismo,  es  fundamental  que  la  di¬ 
rección  se  implique  en  su  desarrollo.  Para  la  descripción  de  la 
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situación  actual,  el  nivel  de  detalle  dependerá  de  la  documentación 
de  que  se  disponga  y  de  la  predisposición  de  la  organización  a  una 
sustitución  total  o  parcial  del  sistema  de  información  actual. 

El  cuadro  completo  de  actividades  que  hay  que  llevar  a  cabo  durante 
esta  fase  es  el  siguiente: 


Figura  10 


Actividades 

1 .  Inicio  del  Plan  de  sistemas  de  información 

El  objetivo  de  esta  primera  actividad  es  la  obtención  de  la 
descripción  general  del  Plan  de  sistemas  de  información, 
identificando  los  objetivos  generales  en  los  que  se  centra, 
y  el  ámbito  al  que  afecta  dentro  de  la  organización. 

Se  deberá  identificar  también  a  los  participantes  en  la 
elaboración  del  plan,  que  definirán  los  factores  críticos 
de  éxito  del  mismo. 

El  método  de  obtención  de  esta  información  es  la  par¬ 
ticipación  en  sesiones  de  trabajo  del  comité  de  direc¬ 
ción  hasta  que  nombre  a  los  gestores  del  proyecto. 

2.  Definición  y  organización  del  plan 

Una  vez  se  han  determinado  los  responsables  del  pro¬ 
yecto,  y  sus  objetivos,  deberemos  detallar  el  alcance  del 
plan,  organizar  el  equipo  de  personas  que  lo  van  a  llevar 
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a  cabo  y  elaborar  un  calendario  de  ejecución.  Este  ca¬ 
lendario  deberá  incluir  una  valoración  en  términos 
económicos  a  partir  de  estimaciones,  que  permitan  to¬ 
mar  decisiones  en  cuanto  a  su  aprobación. 

Una  vez  definido  el  plan  de  trabajo  para  la  realización 
del  propio  plan,  se  deberá  comunicar  a  la  dirección  para 
su  aprobación  definitiva. 

3.  Estudio  de  la  información  relevante 

La  primera  actividad,  una  vez  aprobado  el  plan,  deberá 
ser  la  recopilación  y  análisis  de  todos  los  antecedentes 
generales  que  puedan  afectar  a  los  procesos  y  recursos 
contemplados  en  el  plan,  así  como  los  resultados  que 
presentaron.  De  especial  interés  serán  los  estudios  reali¬ 
zados  con  anterioridad,  relativos  a  los  sistemas  de 
información  del  ámbito  del  plan  como  a  su  entorno 
tecnológico. 

La  información  que  obtengamos  será  de  utilidad  para 
realizar  la  toma  de  requisitos  en  actividades  posteriores. 

4.  Identificación  de  requisitos 

La  toma  de  requisitos  se  realizará  mediante  el  estudio  de 
los  procesos  en  el  ámbito  del  plan.  El  modelo  de  estos 
procesos,  ¡unto  con  sus  actividades  y  funciones,  la  infor¬ 
mación  implicada  en  ellos  y  las  unidades  organizativas  o 
recursos  que  en  él  participan,  se  obtendrá  de  reuniones 
de  trabajo  con  usuarios  expertos  o  técnicos  implicados. 

Una  vez  contrastadas  las  conclusiones,  se  elaborará  el 
modelo  de  procesos  implicados,  unificando  en  la  medida 
de  lo  posible  los  que  guarden  relación  entre  ellos,  con  el 
objetivo  de  tener  una  visión  lo  más  general  posible. 

A  continuación  se  deberán  analizar  las  necesidades  de 
información  de  cada  proceso  modelado  anteriormente, 
y  se  elaborará  un  modelo  de  información  que  refleje  las 
principales  entidades  y  las  relaciones  existentes  entre 
ellas  en  términos  de  información  de  entrada/salida,  sus 
actividades  y  sus  funciones. 
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A  continuación  se  deberán  analizar  las  necesidades  de 
información  de  cada  proceso  modelado  anteriormen¬ 
te,  y  se  elaborará  un  modelo  de  información  que  refleje 
las  principales  entidades  y  las  relaciones  existentes  en¬ 
tre  ellas  en  términos  de  información  de  entrada/salida, 
sus  actividades  y  sus  funciones. 

Finalmente,  elaboraremos  el  catálogo  de  requisitos  a 
partir  de  la  información  obtenida  en  actividades  ante¬ 
riores,  y  de  las  necesidades  de  información  y  proceso 
obtenidos  previamente.  Es  importante  priorizar  los  re¬ 
quisitos,  sobre  la  base  de  las  opiniones  de  los  usuarios 
y  los  objetivos  del  plan. 

5.  Estudio  de  los  sistemas  de  información  actuales 

A  partir  de  los  sistemas  actuales  afectados  por  el  plan, 
se  deberá  obtener  una  valoración  de  la  situación  ac¬ 
tual,  basada  en  criterios  como  la  facilidad  de  manteni¬ 
miento,  documentación,  flexibilidad,  facilidad  de  uso, 
nivel  de  servicio,  etc.  Los  usuarios  aportarán  aquí  los 
elementos  de  valoración  más  importantes. 

Es  importante  obtener  una  valoración  lo  más  objetiva 
posible,  ya  que  ésta  va  a  influir  en  la  decisión  de  mejo¬ 
ra  o  sustitución  de  cada  proceso  o  sistema. 

6.  Diseño  del  modelo  de  sistemas  de  información 

En  este  punto  tendremos  información  suficiente  para 
decidir  en  qué  sistemas  aplicamos  mejoras  o  bien  qué 
sistemas  sustituimos,  y  en  cada  caso,  cuál  deberá  ser  el 
sistema  resultante. 

Una  vez  tomadas  estas  decisiones,  debemos  obtener  el 
modelo  de  sistemas  de  información,  que  incluirá  un 
diagrama  de  representación  de  todos  ellos,  con  sus  co¬ 
nexiones  e  interfaces,  y  una  descripción  de  cada  siste¬ 
ma  con  el  conjunto  de  procesos  y  requisitos  que  cubre. 
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7.  Definición  de  la  arquitectura  tecnológica 

En  esta  actividad  debemos  proponer  una  arquitectura 
tecnológica,  a  alto  nivel,  que  dé  soporte  al  modelo  de 
sistemas  de  información,  y  que  puede  incluir,  si  es  ne¬ 
cesario,  opciones.  Para  esta  actividad  tendremos  en 
cuenta  sobre  todo  los  requisitos  de  carácter  tecnológi¬ 
co,  aunque  puede  ser  necesario  comprender  el  catálo¬ 
go  completo  de  requisitos. 

La  definición  y  elección  entre  las  alternativas  posibles 
deberá  realizarse  sobre  la  base  del  entorno  actual,  los 
estándares,  y  apoyándonos  en  análisis  coste/beneficio 
e  impacto  en  la  organización  de  cada  alternativa. 

8.  Definición  del  plan  de  acción 

El  plan  de  acción  será  el  que  definirá  los  proyectos  con¬ 
cretos  a  llevar  a  cabo  para  la  implantación  de  los  sistemas 
y  modelos  de  información  definidos  en  las  actividades  an¬ 
teriores. 

Dentro  del  plan  de  acción,  se  incluirá  un  calendario  de 
proyectos,  con  posibles  alternativas  y  una  estimación 
de  recursos.  Para  la  elaboración  de  este  plan,  será  im¬ 
portante  tener  en  cuenta  las  prioridades  que  habremos 
marcado  en  materia  de  requisitos,  y  los  sistemas  impli¬ 
cados  en  cada  uno  de  ellos. 

Por  último,  también  será  importante  la  realización  de  un 
plan  de  mantenimiento  y  control  de  la  ejecución  de  los 
proyectos. 

9.  Revisión  y  aprobación  del  plan 

Finalmente,  debemos  presentar  la  arquitectura  de  infor¬ 
mación  diseñada  y  el  plan  de  acción  a  los  responsables 
de  la  dirección  del  mismo.  Mejoraremos  la  propuesta  si 
es  necesaria  y  obtendremos  la  aprobación  final. 


43 


Software  libre 


Desarrollo  de  sistemas  de  información 

El  plan  de  sistemas  tenía  como  objetivo  proporcionar  un  marco  es¬ 
tratégico  que  sirva  de  referencia.  Una  vez  completado  el  plan  de  ac¬ 
ción,  pasaremos  al  desarrollo  de  cada  proyecto. 

En  él,  algunas  actividades  serán  réplicas  de  actividades  realizadas  en 
el  plan  de  sistemas  (toma  de  requisitos,  análisis  de  la  situación  ac¬ 
tual,  etc.).  Si  el  plan  se  ha  realizado  con  el  suficiente  nivel  de  detalle, 
o  se  refería  únicamente  a  un  proyecto  concreto,  estas  actividades  no 
serán  necesarias.  En  caso  contrario,  serán  las  primeras  en  llevarse  a 
cabo  en  este  proceso. 

Estudio  de  viabilidad 


Si  el  plan  de  sistemas  nos  ha  dejado  con  varias  alternativas  para  un 
proyecto  en  concreto,  en  la  primera  fase  deberemos  estudiar  la  via¬ 
bilidad  de  cada  una,  en  términos  de  impacto  en  la  organización  e 
inversión  a  realizar. 


En  todo  caso,  la  primera  actividad  que  Métrica  v3  define  en  la  fase 
de  desarrollo  es  el  estudio  de  la  viabilidad  del  proyecto,  que  debería 
generar  uno  o  varios  documentos  (según  las  alternativas  considera¬ 
das)  con  un  índice  como  el  que  sigue: 

Solución  propuesta: 

Descripción  de  la  solución 

Modelo  de  descomposición  en  subsistemas 
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Matriz  procesos  /  Localización  geográfica 
Matriz  datos  /  Localización  geográfica 
Entorno  tecnológico  y  comunicaciones 
Estrategia  de  implantación  global  del  sistema 
Descripción  de  procesos  manuales 


Si  la  alternativa  incluye  desarrollo: 

Modelo  abstracto  de  datos  /  Modelo  de  procesos 
Modelo  de  negocio  /  Modelo  de  dominio 


Si  la  alternativa  incluye  un  producto  software  estándar  de  mercado: 


Descripción  del  producto 

Evolución  del  producto 

Costes  ocasionados  por  el  producto 

Estándares  del  producto 

Descripción  de  adaptación  (si  es  necesaria) 

Contexto  del  sistema  (con  la  definición  de  las  interfaces) 

Impacto  en  la  organización  de  la  solución 

Coste  /  Beneficio  de  la  solución 

Valoración  de  riesgos  de  la  solución 

Enfoque  del  plan  de  trabajo  de  la  solución 

Planificación  de  la  solución 

Análisis  del  sistema  de  información 

El  objetivo  de  este  proceso  es  la  obtención  de  una  especificación  de¬ 
tallada  del  sistema  de  información  que  satisfaga  las  necesidades  de 
los  usuarios  y  sirva  de  base  para  el  posterior  diseño  del  sistema. 


Métrica  v3  soporta  el  desarrollo  tanto  con  lenguajes  estructurados, 
como  orientados  a  objetos,  pero  las  actividades  particulares  en  cada 
caso  están  integradas  en  una  estructura  común. 
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Figura  12 


Las  dos  primeras  actividades  serán  recuperar  y  profundizar  en  la  de¬ 
finición  del  sistema  y  la  toma  de  requisitos  del  mismo,  con  el  objetivo 
de  detallar  al  máximo  el  catálogo  de  requisitos  y  describir  con  preci¬ 
sión  el  sistema  de  información. 


A  continuación  empezará  el  cuerpo  del  análisis,  formado  por  cuatro 
actividades  que  se  realimentarán  entre  sí,  hasta  tener  el  análisis  com¬ 
pleto  del  sistema.  De  las  cuatro  actividades,  dos  son  comunes  para 
desarrollos  estructurados  u  orientados  a  objetos,  mientras  que  las 
otras  dos  son  diferentes  en  cada  caso. 


Las  actividades  son: 


46 


Identificación  de  subsistemas  de  análisis:  facilitar  el  análisis  me¬ 
diante  la  descomposición  del  sistema  en  subsistemas.  Actividades 
posteriores  pueden  obligar  a  revisar  esta  descomposición. 


Análisis  de  casos  de  uso  (elaboración  del  modelo  de  datos  en  len¬ 
guaje  estructurado). 


•  Análisis  de  clases  (elaboración  del  modelo  de  procesos  en  len¬ 
guaje  estructurado). 


•  Definición  de  interfaces  de  usuario. 


Finalmente,  deberemos  verificar  y  validar  los  modelos  con  el  fin  de 
asegurar  que  son: 


•  Completos:  cada  modelo  contiene  toda  la  información  necesaria. 


•  Consistentes:  cada  modelo  es  coherente  con  el  resto. 


•  Correcto:  el  modelo  sigue  las  normas  de  calidad,  estándares  y 
nomenclatura  determinadas  en  actividades  anteriores. 


Como  última  actividad  del  análisis,  se  deberá  especificar  el  plan  de 
pruebas  del  sistema.  Se  trata  únicamente  de  iniciar  su  especificación, 
que  se  detallará  en  actividades  posteriores.  Contemplando  el  alcan¬ 
ce  de  las  mismas,  los  requisitos  del  entorno  de  pruebas,  y  la  defini¬ 
ción  de  las  pruebas  de  aceptación  es  suficiente. 


Diseño  del  sistema  de  información 

El  objetivo  de  esta  actividad  es  la  especificación  detallada  de  la  ar¬ 
quitectura  del  sistema  y  del  entorno  tecnológico  que  le  va  a  dar  so¬ 
porte,  ¡unto  con  los  componentes  del  sistema  de  información. 
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Figura  13 


A  partir  de  esta  información,  generaremos  las  especificaciones  de 
construcción  del  sistema,  así  como  la  descripción  técnica  del  plan 
de  pruebas,  la  definición  de  requisitos  de  implantación  y  el  diseño  de 
procedimientos  de  migración  y  carga  inicial  si  procede. 


Las  actividades  de  este  proceso  se  dividen  en  dos  bloques: 


El  primer  bloque  de  actividades  se  realiza  en  paralelo,  y  comprende: 


•  Definición  de  la  arquitectura  del  sistema  de  información:  se  esta¬ 
blece  la  partición  física  del  sistema  de  información,  y  su  corres¬ 
pondencia  con  los  subsistemas  de  diseño.  También  definiremos 
sus  requisitos  de  operación,  administración,  seguridad  y  control 
de  acceso.  Los  subsistemas  de  diseño  se  deberán  clasificar  en: 


-  Subsistemas  de  soporte:  contienen  elementos  o  servicios  comunes 
al  sistema  y  a  la  instalación.  Generalmente  originados  por  la  in¬ 
teracción  con  la  infraestructura  técnica,  o  por  la  reutilización. 
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-  Subsistemas  específicos:  contienen  los  elementos  propios  del  sis¬ 
tema  de  información,  como  continuidad  de  los  vistos  en  la  activi¬ 
dad  de  análisis  del  sistema. 


•  Diseño  de  casos  de  uso  reales:  es  el  diseño  detallado  del  compor¬ 
tamiento  del  sistema  para  los  casos  de  uso,  ¡unto  con  la  interfaz 
de  usuario. 


•  Diseño  de  clases:  detallado  con  atributos,  operaciones,  relacio¬ 
nes,  métodos  y  la  estructura  jerárquica  de  todo  el  modelo. 


•  Diseño  físico  de  datos  una  vez  obtenido  el  modelo  de  clases. 


En  el  segundo  bloque  de  actividades,  se  generan  todas  las  especifi¬ 
caciones  necesarias  para  la  construcción: 


•  Generación  de  especificaciones  de  construcción  que  fijan  las  di¬ 
rectrices  para  la  construcción  de  los  componentes  del  sistema. 


•  Diseño  de  la  migración  y  carga  inicial  de  datos. 


•  Especificación  técnica  del  plan  de  pruebas.  Realizar  un  catálogo 
de  excepciones  permitirá  establecer  un  conjunto  de  verificaciones 
relacionadas  con  el  diseño  o  con  la  propia  arquitectura. 


•  Establecimiento  de  requisitos  de  implantación. 


Construcción  del  sistema  de  información 


En  este  proceso  se  genera  el  código  de  los  componentes  del  sistema 
de  información,  se  desarrollan  todos  los  procedimientos  de  opera¬ 
ción  y  seguridad  y  se  elaboran  los  manuales  de  usuario  y  de  explo¬ 
tación. 
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Un  objetivo  clave  en  esta  fase  será  asegurar  el  correcto  funciona¬ 
miento  del  sistema  para  su  aceptación  y  posterior  implantación.  Para 
conseguirlo,  en  este  proceso  se  realizarán  las  pruebas  unitarias,  las 
pruebas  de  integración  de  los  subsistemas  y  las  pruebas  de  sistema, 
de  acuerdo  con  el  plan  establecido. 


La  base  para  la  construcción  del  sistema  es  la  especificación  de  cons¬ 
trucción  obtenida  en  el  proceso  de  diseño  anterior.  Una  vez  configu¬ 
rado  el  entorno  de  desarrollo,  se  realizará  la  codificación  y  las  pruebas 
de  acuerdo  con  las  siguientes  actividades: 


•  Generación  del  código:  conforme  a  las  especificaciones  de  cons¬ 
trucción  y  al  plan  de  integración  de  los  subsistemas. 

•  Ejecución  de  las  pruebas  unitarias:  conforme  al  plan  de  pruebas 
diseñado. 

•  Ejecución  de  las  pruebas  de  integración:  verificaciones  asociadas 
a  los  componentes  y  subsistemas. 
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•  Ejecución  de  pruebas  de  sistema:  integración  final  del  sistema  de 
información,  comprobando  tanto  las  interfaces  entre  subsistemas 
y  sistemas  externos,  como  los  requisitos. 

•  Elaboración  del  manual  de  usuario:  documentación  de  usuario  fi¬ 
nal  y  de  explotación. 

•  Formación  de  usuarios  finales. 

•  Construcción  de  los  componentes  y  procedimientos  de  migración 
y  carga  inicial  de  datos. 

Implantación  y  aceptación  del  sistema 


El  objeto  de  este  proceso  es  la  entrega  y  aceptación  del  sistema  en 
su  totalidad,  así  como  la  realización  de  las  actividades  necesarias 
para  su  paso  a  producción. 


En  éste,  deberemos: 


•  Revisar  la  estrategia  de  implantación  determinada  en  el  estudio 
de  viabilidad  del  sistema. 

•  Preparar  la  infraestructura  necesaria,  la  instalación  de  los  compo¬ 
nentes,  la  activación  de  los  procedimientos  manuales  y  automáti¬ 
cos,  y  la  migración  o  carga  inicial  de  datos. 
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•  Realizar  las  pruebas  de  implantación  y  aceptación  del  sistema  en 
su  totalidad. 

•  Preparar  el  mantenimiento. 

•  Determinar  los  requisitos  de  los  servicios  que  requiere  el  sistema. 
Habrá  que  distinguir  entre  servicios  de  operaciones  (seguridad, 
comunicaciones,  etc.)  y  servicios  al  cliente  (atención  al  usuario, 
mantenimiento,  etc.). 

•  El  plan  de  implantación  puede  definir  este  proceso  de  forma  ite¬ 
rativa,  poniendo  en  marcha  los  subsistemas  y  realizando  estas  ac¬ 
tividades  para  cada  uno  de  ellos. 


Mantenimiento  de  sistemas  de  información 


El  proceso  de  mantenimiento  tiene  como  objeto  la  puesta  en  marcha  de 
una  nueva  versión  del  sistema  o  proyecto  a  partir  de  las  peticiones 
de  los  usuarios  con  motivo  de  un  problema  detectado  en  el  sistema 
o  por  una  necesidad  de  mejora  del  mismo. 


Una  vez  recibida  una  petición,  ésta  se  incorpora  a  un  catálogo  de  pe¬ 
ticiones,  y  se  procede  a  diagnosticar  de  qué  tipo  de  mantenimiento 
se  trata: 

•  Correctivo:  cambios  precisos  para  corregir  errores. 

•  Evolutivo:  modificaciones  necesarias  para  cubrir  la  expansión  o 
cambio  en  las  necesidades. 

•  Adaptativo:  modificaciones  que  afectan  al  entorno  en  que  el  pro¬ 
yecto  opera,  cambios  de  configuración,  de  hardware,  bases  de 
datos,  comunicaciones,  etc. 

52 


•  Perfectivo:  acciones  llevadas  a  cabo  para  mejorar  la  calidad  in¬ 
terna  de  los  sistemas.  Reestructuración  de  código,  optimización 
de  rendimiento,  eficiencia,  etc. 

El  siguiente  paso  que  define  Métrica  v3  es  la  determinación  de  la  res¬ 
ponsabilidad  en  atender  la  petición.  La  petición  puede  ser  aceptada 
o  rechazada,  en  cuyo  caso  se  registra  y  termina  el  proceso.  En  caso 
de  aceptarse,  habrá  que  estudiar  la  viabilidad  del  cambio,  verificar 
y  reproducir  el  problema  y  estudiar  el  alcance  de  la  modificación. 

El  plazo  y  urgencia  de  la  petición  debe  establecerse  según  los  pará¬ 
metros  del  estudio  anterior.  Mediante  este  análisis,  la  persona  encar¬ 
gada  del  mantenimiento  deberá  valorar  el  coste  y  esfuerzo  necesario 
para  la  implementación  de  la  modificación. 

Las  tareas  de  procesos  de  desarrollo  se  corresponden  con  las  de  los  pro¬ 
cesos  de  análisis,  diseño,  construcción  e  implantación.  Finalmente,  es 
importante  establecer  un  plan  de  pruebas  de  regresión  que  asegure  la 
integridad  del  sistema  afectado. 

El  registro  de  las  peticiones  recibidas  puede  utilizarse  también  para 
fines  estadísticos  (peticiones  atendidas,  sistemas  afectados,  etc.),  y  un 
registro  minucioso  de  las  actividades  realizadas,  una  documentación 
extensa  de  los  cambios  incorporados  al  sistema  repercutirá  directa¬ 
mente  en  la  calidad  de  los  sistemas  resultantes  y  en  tener  el  coste  del 
mantenimiento  bajo  control. 


Interfaces 

Al  ser  Métrica  v3  una  metodología  fuertemente  estructurada,  y  a  pe¬ 
sar  de  que  su  aplicación  proporciona  sistemas  con  calidad  y  seguri¬ 
dad,  se  han  definido  unas  interfaces  que  refuerzan  éstos  y  otros 
aspectos  a  lo  largo  de  todos  sus  procesos.  Las  interfaces  descritas  en 
la  metodología  son: 

•  Gestión  de  proyectos 

•  Seguridad 

•  Aseguramiento  de  la  calidad 

•  Gestión  de  la  configuración 
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Gestión  de  proyectos 


La  gestión  de  proyectos  tiene  como  finalidad  principal  la  planifica¬ 
ción,  el  seguimiento  y  control  de  las  actividades  y  de  los  recursos  hu¬ 
manos  y  materiales  que  intervienen  en  el  desarrollo  del  sistema  de 
información  o  del  proyecto.  El  objetivo  de  este  control  es  la  identifi¬ 
cación  en  todo  momento  de  los  problemas  que  se  produzcan  y  de  su 
resolución  o  la  capacidad  de  mitigarlos  de  forma  inmediata. 


•  GPI:  Las  actividades  de  inicio  del  proyecto  se  realizarán  al  concluir  el 
estudio  de  viabilidad  del  mismo,  y  consistirán  en  la  estimación  del  es¬ 
fuerzo  y  en  la  propia  planificación  del  proyecto.  Para  la  estimación 
del  esfuerzo,  partiremos  de  la  descomposición  en  subsistemas  ob¬ 
tenido  del  estudio  de  viabilidad  y  de  los  elementos  implicados 
(funciones,  entidades  y  datos  en  desarrollos  estructurados  o  cla¬ 
ses,  propiedades  y  métodos  en  desarrollos  orientados  a  objeto). 

Para  el  cálculo  del  esfuerzo,  Métrica  v3  propone  la  utilización  de 
técnicas  conocidas  como  el  método  Albrecht  o  los  puntos  de  fun¬ 
ción  (en  desarrollo  estructurado)  o  bien  la  métrica  Staffing  Size  en 
el  caso  de  desarrollo  orientado  a  objetos. 


Métrica  v3  no  da  recomendaciones  en  cuanto  a  la  estrategia  de 
desarrollo,  simplemente  enumera  las  existentes  (en  cascada,  por 
subsistemas,  por  prototipo  o  híbrida)  y  deja  la  elección  en  manos 
del  ¡efe  de  proyecto. 


En  cuanto  a  la  descomposición  detallada  de  actividades  y  la  asig¬ 
nación  de  recursos,  Métrica  v3  recomienda  el  uso  del  método 
PERT  y  los  diagramas  de  Gantt,  conjuntamente  con  tablas  de 
asignación  de  recursos. 
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•  GPS:  Las  actividades  de  seguimiento  y  control  comprenden  desde 
la  asignación  de  tareas  hasta  su  aceptación  interna,  incluyendo  la 
gestión  de  incidencias,  cambios  en  los  requisitos  y  la  vigilancia  del 
correcto  desarrollo  de  las  tareas  y  actividades  establecidas  en  la 
planificación. 

Para  ello,  Métrica  v3  enumera  las  actividades  que  deben  tener  lugar 
en  paralelo  al  análisis,  diseño,  construcción,  implantación  y  mante¬ 
nimiento  del  proyecto.  Las  resumimos  en  la  siguiente  figura. 


•  GPF:  Por  último,  al  concluir  el  proyecto,  se  realizan  las  actividades 
propias  de  cierre  del  mismo  y  registro  de  la  documentación  que 
incluye. 


El  cierre  del  proyecto  consiste  en  resumir  todos  los  datos  de  éste 
que  se  consideren  de  interés,  para  que  puedan  servir  de  referen¬ 
cia  a  proyectos  futuros,  aprovechando  las  experiencias  habidas  y 
tratando  de  incurrir  en  los  mismos  errores. 

Seguridad 

El  objetivo  de  esta  interfaz  es  incorporar  mecanismos  de  seguridad 
adicionales  a  los  que  se  proponen  como  parte  de  la  propia  metodo¬ 
logía,  estableciendo  un  conjunto  de  actividades  que  tienen  lugar  a  lo 
largo  de  todo  el  proceso. 
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Dentro  de  la  interfaz,  existen  dos  tipos  de  actividades  diferenciadas: 


•  Actividades  relacionadas  con  la  seguridad  intrínseca  del  sistema 
que  se  va  a  desarrollar.  Son  actividades  de  análisis  en  detalle  de 
los  requisitos  de  seguridad  que  tienen  lugar  durante  la  planifica¬ 
ción,  el  estudio  de  viabilidad  y  el  análisis  y  diseño  del  sistema. 

•  Actividades  que  cuidan  de  la  seguridad  del  propio  proceso  de  de¬ 
sarrollo. 

Si  en  la  organización  ya  existe  un  plan  de  seguridad  o  metodología 
de  análisis  y  gestión  de  riesgos,  deberá  aplicarse  para  detectar  aque¬ 
llas  necesidades  que  no  se  encuentren  cubiertas  y  tomar  las  decisio¬ 
nes  en  función  de  los  riesgos  que  se  quiera  asumir  o  mitigar. 

Si  no  existe  un  plan  de  seguridad,  habrá  que  desarrollarlo  desde  el 
principio.  El  plan  deberá  recoger  las  medidas  de  seguridad  activas, 
preventivas  y  reactivas  en  respuesta  a  situaciones  en  las  que  pueda  pro¬ 
ducirse  un  fallo,  reduciendo  su  efecto,  tanto  si  estamos  tratando  con  el 
sistema  de  información  o  proyecto  en  sí  como  durante  el  proceso  de 
desarrollo. 

Aseguramiento  de  la  calidad 

El  objetivo  de  esta  interfaz  es  proveer  un  marco  de  referencia  para  la 
definición  y  puesta  en  marcha  de  planes  específicos  de  aseguramien¬ 
to  de  la  calidad  del  proyecto.  Lo  que  se  pretende  es  dar  confianza  en 
que  el  producto  cumple  con  los  requisitos. 

Métrica  v3  recomienda  que  el  grupo  de  aseguramiento  de  la  calidad 
sea  totalmente  independiente  del  de  desarrollo,  y  tendrá  como  mi¬ 
sión  identificar  las  posibles  desviaciones  en  los  estándares,  requisitos 
y  procedimientos  establecidos,  así  como  comprobar  que  se  han  lle¬ 
vado  a  cabo  las  medidas  preventivas  o  correctoras  necesarias. 

Para  un  resultado  óptimo  de  esta  interfaz,  deberá  aplicarse  desde  el 
estudio  de  la  viabilidad  del  sistema  y  a  lo  largo  de  todo  el  desarrollo, 
en  los  procesos  de  análisis,  diseño,  construcción,  implantación  y  man¬ 
tenimiento  del  proyecto. 
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Gestión  de  la  configuración 


El  objetivo  de  esta  interfaz  es  crear  y  mantener  un  registro  de  todos 
los  productos  creados  o  usados  durante  el  proyecto.  Sus  actividades 
tienen  lugar  a  lo  largo  de  todo  el  proyecto,  se  encargarán  de  man¬ 
tener  la  integridad  de  los  productos,  de  asegurarnos  de  que  cada 
persona  involucrada  dispone  de  la  última  versión  de  todos  ellos,  y  de 
que  disponemos  de  toda  la  información  acerca  de  cambios  produci¬ 
dos  en  sus  configuraciones,  requisitos,  etc. 

Al  hablar  de  productos,  no  nos  referimos  únicamente  a  código  fuente 
y  ejecutables,  también  a  todo  el  material  y  documentación  generados 
durante  el  proyecto,  diagramas,  manuales,  estudios  y  análisis  que  se 
hayan  revisado,  etc. 

Nos  ayudará  a  valorar  el  impacto  de  cada  cambio  en  el  sistema,  y  a 
reducir  su  tiempo  de  implementación.  El  cumplimiento  y  coste  de  im- 
plementación  de  esta  interfaz  no  deben  menospreciarse,  si  la  orga¬ 
nización  ya  disponía  de  un  sistema  de  gestión  de  configuraciones, 
sus  actividades  se  desarrollarán  con  más  facilidad  y  rapidez. 

La  información  que  podría  solicitarse  al  sistema  de  gestión  de  confi¬ 
guración  es  muy  amplia: 

•  Información  sobre  una  fase  del  proyecto  concreta,  análisis,  cons¬ 
trucción,  etc. 

•  Información  sobre  la  "vida"  de  un  producto,  sus  versiones,  perso¬ 
nas  involucradas,  etc. 

Sus  actividades  se  distribuirán  a  lo  largo  de  las  distintas  fases,  una  vez 
determinada  la  selección  de  la  solución  en  el  estudio  de  viabilidad,  se 
seleccionará  el  entorno  tecnológico  donde  se  registrará  la  configuración 
del  proyecto,  y  de  ahí  en  adelante  se  pondrá  en  marcha  el  proceso. 

En  cada  una  de  las  fases  siguientes,  análisis,  diseño,  etc.  se  irán  re¬ 
gistrando  los  cambios  en  los  productos,  y  al  final  de  cada  fase  se 
anotarán  en  el  registro  global. 


Evidentemente,  en  el  proceso  de  mantenimiento,  esta  interfaz  ad¬ 
quiere  una  importancia  especial,  ya  que  la  información  de  que  dis¬ 
pondremos  al  valorar  cada  nuevo  cambio  reducirá  y  compensará  lo 
invertido  a  lo  largo  de  las  otras  fases.  El  trabajo  también  será  inten¬ 
so,  ya  que  nuevas  versiones  se  sucederán  más  rápidamente  y  habrá 
que  incorporarlas  y  notificarlas  al  registro  de  configuraciones. 


Conclusiones 

Tanto  por  su  lenguaje,  como  por  el  tipo  y  número  de  actividades  plan¬ 
teadas,  se  detecta  rápidamente  que  Métrica  v3  es  una  metodología 
impulsada  por  una  administración  pública.  Tal  como  comentamos  al 
inicio,  su  mérito  radica  en  la  propia  elaboración  de  la  metodología  y 
no  tanto  en  sus  planteamientos,  que  son  de  lo  más  clásico. 

Si  nos  sentimos  cómodos  con  este  tipo  de  metodologías,  un  aspecto 
muy  interesante  es  la  documentación  que  proporciona  sobre  las  téc¬ 
nicas  (documentos,  plantillas,  listas  de  comprobación,  etc.)  que  cabe 
aplicar  en  cada  actividad.  También  es  muy  conveniente  la  definición 
concreta  que  realiza  sobre  las  entradas  y  salidas  de  cada  actividad. 
Aunque  nuestra  metodología  basada  en  Métrica  v3  no  siga  al  pie  de 
la  letra  todas  las  actividades  planteadas,  un  estudio  de  los  documen¬ 
tos  que  deberemos  obtener  y  utilizar  en  cada  fase  puede  ser  de  gran 
ayuda  para  asegurarnos  de  que  no  nos  dejamos  nada  antes  de  pa¬ 
sar  a  la  siguiente  fase  del  proyecto. 


1 .6.  Resumen 


A  lo  largo  de  este  capítulo,  hemos  dado  un  repaso  general  a  la  in¬ 
geniería  del  software.  Hemos  visto  los  problemas  que  tuvieron  los 
primeros  gestores  de  grandes  proyectos,  y  conocido  los  conceptos 
que  deben  tenerse  en  cuenta  en  el  momento  de  plantearse  un  pro¬ 
yecto  software  de  cualquier  envergadura. 

Los  dos  ejemplos  de  metodologías  planteados,  aunque  muy  diferen¬ 
tes,  intentan  solucionar  los  mismos  problemas,  y  organizaciones  o 
proyectos  diferentes  se  encontrarán  más  próximos  a  una  u  otra  indis¬ 
tintamente. 
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A  lo  largo  del  resto  de  capítulos,  veremos  la  aplicación  práctica  de 
muchos  de  los  conceptos  introducidos  aquí  en  el  ámbito  concreto  del 
software  libre  y  los  estándares. 
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2.  Diseño  de  software  orientado  a  objeto  con  UML 


2.1 .  Introducción 

El  análisis  y  diseño  del  software  constituye  una  parte  fundamental  en 
cualquier  proyecto,  independientemente  de  su  tamaño.  Todas  las 
metodologías,  en  mayor  o  menor  medida,  o  con  distintos  alcances, 
dan  una  gran  importancia  a  estas  fases  como  paso  intermedio  entre 
la  toma  de  requisitos  y  el  desarrollo  del  proyecto. 

Como  parte  de  lo  que  se  considera  "Ingeniería  del  software",  el  mo¬ 
delado  y  diseño  ha  ido  evolucionando  a  lo  largo  del  tiempo  median¬ 
te  técnicas  aportadas  tanto  por  especialistas  del  ámbito  académico, 
como  por  empresas  especializadas  en  consultorio  y  desarrollo. 

Existen  muchas  técnicas  orientadas  a  modelar  un  aspecto  de  los  sis¬ 
temas  de  información,  bases  de  datos,  interfaces  de  usuario,  compo¬ 
nentes,  flujos  de  datos,  etc.,  pero  pocas  han  aportado  un  enfoque 
global  al  problema. 

A  finales  de  los  años  noventa,  una  empresa  en  particular  (Rational 
Corp.)  empezó  una  iniciativa  para  desarrollar  un  estándar  de  mode¬ 
lado  a  la  que  se  sumaron  científicos  y  otras  empresas  del  sector.  Así 
nació  UML  ( Unified  Modellng  Language ),  que  hoy  en  día  sigue  sien¬ 
do  el  método  de  modelado  más  completo  y  aceptado  en  la  industria. 

El  método  de  modelado  está  basado  en  el  paradigma  de  programa¬ 
ción  orientado  a  objetos,  que  en  ese  momento  empezaba  a  popula¬ 
rizarse  y  hoy  en  día  sigue  siendo  (con  alguna  variación  y  revisión)  el 
más  usado  en  todo  tipo  de  proyectos. 

Por  ello,  en  este  capítulo  empezaremos  comentando  este  paradigma 
de  programación  y  sus  aspectos  fundamentales.  No  se  ha  pretendido 
hacer  un  tratado  completo  sobre  la  orientación  a  objetos,  sino  pro¬ 
porcionar  una  base  para  comprender  los  conceptos  que  soportará 
cada  tipo  de  diagrama. 
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Software  libre 


A  continuación  presentaremos  un  ejemplo  práctico  que  iremos  si¬ 
guiendo  a  lo  largo  del  capítulo  y  aplicando  en  cada  apartado  corres¬ 
pondiente  un  tipo  de  diagrama  UML. 

Finalmente,  comentaremos  otra  utilidad  de  UML,  la  generación  de 
código  a  partir  de  ciertos  tipos  de  diagramas.  Presentaremos  tres  he¬ 
rramientas  de  código  abierto  muy  populares  y  veremos  sus  presta¬ 
ciones  en  este  ámbito. 


2.2.  Objetivos 

Los  objetivos  que  el  estudiante  deberá  haber  logrado  al  finalizar  el 
capítulo  de  "Diseño  de  software  orientado  a  objeto  con  UML"  del 
material  "Ingeniería  del  software  en  entornos  de  software  libre"  son 
los  siguientes: 

•  Tener  claros  los  conceptos  más  importantes  relacionados  con  la 
orientación  a  objetos  tanto  a  nivel  de  su  análisis  y  diseño  como  a 
nivel  de  implementación. 

•  Conocer  los  distintos  tipos  de  diagramas  UML,  sus  cometidos  y 
particularidades. 

•  Disponer  de  los  conocimientos  necesarios  para  afrontar  el  análi¬ 
sis  y  diseño  de  un  proyecto  software  y  representar  su  modelo  me¬ 
diante  UML. 

•  Conocer  algunas  herramientas  de  modelado  y  generación  de  có¬ 
digo  e  identificar  la  más  idónea  para  un  proyecto  concreto. 


2.3.  Revisión  de  conceptos  del  diseño  orientado 
a  objeto  y  UML 

El  presente  apartado  tiene  como  objetivo  introducir  los  conceptos  del 
análisis,  el  diseño  y  la  programación  orientada  a  objeto  necesarios 
para  poder  asimilar  el  resto  del  capítulo  y  entender  el  caso  práctico 
que  plantearemos. 
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2.3.1.  Introducción  a  la  orientación  a  objetos 


La  orientación  a  objetos  es  un  paradigma  más  de  programación  en 
el  que  un  sistema  se  expresa  como  un  conjunto  de  objetos  que  inte¬ 
ractúan  entre  ellos.  Un  paradigma  de  programación  nos  proporcio¬ 
na  una  abstracción  del  sistema  real  a  algo  que  podemos  programar 
y  ejecutar,  y  puede  decirse  que  el  tipo  de  abstracción  está  directa¬ 
mente  relacionada  con  los  problemas  que  puede  resolver  o  al  menos 
con  la  facilidad  con  que  podremos  resolverlos.  Mientras  que  el  len¬ 
guaje  ensamblador  es  una  abstracción  del  procesador,  podríamos 
decir  que  otros  lenguajes  de  programación  como  BASIC  o  C  son  abs¬ 
tracciones  del  propio  lenguaje  ensamblador.  Aunque  han  supuesto 
un  importante  avance  sobre  éste,  aún  obligan  a  los  programadores 
a  pensar  en  términos  de  la  estructura  del  ordenador  en  lugar  de  la 
estructura  del  problema  que  están  intentando  solucionar. 

Otros  lenguajes  han  intentado  modelar  el  problema  presentando  vi¬ 
siones  diferentes  del  mundo  (todos  los  problemas  son  listas  en  USP, 
todos  los  problemas  son  una  cadena  de  decisiones  en  PROLOG).  Es¬ 
tas  visiones  son  buenas  soluciones  para  el  tipo  de  problemas  que  se 
ajustan  a  esa  visión,  pero  cuando  nos  salimos  de  ella,  el  paradigma 
empieza  a  no  ser  tan  útil. 

La  orientación  a  objetos  da  un  paso  más  y  nos  proporciona  las  he¬ 
rramientas  para  representar  elementos  en  el  espacio  del  problema 
concreto.  No  nos  impone  ninguna  restricción  a  priori,  de  forma  que 
el  programador  no  está  limitado  a  cierta  clase  de  problemas.  Los 
elementos  en  el  espacio  del  problema  y  su  representación  es  lo  que 
llamamos  "objetos". 

Alan  Kay  resumió  las  cinco  características  básicas  de  Smalltalk,  el 
primer  lenguaje  de  programación  puramente  orientado  a  objetos, 
en  el  que  están  basados  tanto  C  +  +  como  Java: 

•  Todo  es  un  objeto:  pensemos  en  un  objeto  como  una  "gran  va¬ 
riable";  almacena  datos,  pero  también  podemos  hacerle  peticio¬ 
nes  para  que  haga  operaciones  sobre  ella  misma.  En  teoría, 
podemos  escoger  cualquier  componente  conceptual  del  proble¬ 
ma  que  queremos  resolver  (estudiantes,  edificios,  servicios,  etc.)  y 
representarlo  como  un  objeto  en  nuestro  programa. 
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•  Un  programa  es  un  conjunto  de  objetos  que  se  dicen  unos  a 
otros  lo  que  deben  hacer  mediante  mensajes:  para  hacer  una 
petición  a  un  objeto,  le  mandamos  un  mensaje.  Podemos  pensar 
en  el  mensaje  como  la  petición  para  llamar  a  un  método  que  per¬ 
tenezca  a  un  objeto  (enviarNota,  activarAlarma,  imprimelnforme). 

•  Cada  objeto  tiene  su  propia  memoria  hecha  de  otros  objetos: 

dicho  de  otra  forma,  crearemos  un  nuevo  tipo  de  objeto  empa¬ 
quetando  otros  objetos  existentes.  Así  podremos  construir  progra¬ 
mas  de  mucha  complejidad  escondiéndola  en  simples  objetos. 

•  Cada  objeto  tiene  un  tipo:  o  dicho  de  otra  forma,  cada  objeto  es 
una  instancia  de  una  clase.  Aquí  utilizamos  clase  como  sinónimo 
de  "tipo".  La  característica  más  importante  de  una  clase  es  "¿Qué 
mensajes  podremos  enviarle?". 

•  Todos  los  objetos  de  un  tipo  particular  pueden  recibir  los  mis¬ 
mos  mensajes:  al  ser  un  objeto  de  tipo  "círculo",  también  un  ob¬ 
jeto  de  tipo  "figura",  un  círculo  podrá  recibir  mensajes  para 
figuras.  Esto  significa  que  podemos  escribir  código  que  hable  con 
"figuras"  y  automáticamente  estaremos  preparados  para  hablar 
con  cualquier  objeto  de  ese  tipo. 

La  definición  del  paradigma  no  ha  llegado  a  consensuarse  nunca, 
pero  en  su  forma  más  general  podríamos  decir  que  expresa  el  hecho 
de  ver  el  programa  en  términos  de  las  cosas  (los  objetos)  que  mani¬ 
pula,  en  lugar  de  las  acciones  que  realiza.  Hoy  en  día,  entendemos 
por  un  lenguaje  orientado  a  objeto  el  que  nos  proporciona  las  si¬ 
guientes  prestaciones: 

•  Objetos:  empaquetan  los  datos  y  la  funcionalidad  conjuntamen¬ 
te.  Son  la  base  para  la  estructura  y  la  modularidad  en  un  software 
orientado  a  objetos. 

•  Abstracción:  la  habilidad  de  un  programa  para  ignorar  ciertos  as¬ 
pectos  de  la  información  que  está  manipulando.  Cada  objeto  del 
sistema  es  un  modelo  de  un  "actor"  que  puede  trabajar  en  el  sis¬ 
tema,  informar  o  cambiar  su  estado  y  comunicarse  con  otros  ob¬ 
jetos,  sin  revelar  cómo  están  implementadas  estas  prestaciones. 
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•  Encapsulación:  asegurar  que  los  usuarios  de  un  objeto  no  pue¬ 
den  cambiar  su  información  o  estado  de  formas  permitidas.  Sólo 
los  propios  métodos  que  ofrece  el  objeto  deben  poder  cambiar  su 
información.  Cada  objeto  ofrece  una  interfaz  que  especifica 
cómo  el  resto  de  objetos  deben  trabajar  con  él.  El  objetivo  de  esta 
encapsulación  es  mantener  la  integridad  del  objeto. 


•  Polimorfismo:  diferentes  objetos  pueden  tener  la  misma  interfaz 
para  responder  al  mismo  tipo  de  mensaje,  y  hacerlo  apropiada¬ 
mente  según  su  naturaleza. 


•  Herencia:  organiza  y  facilita  el  polimorfismo  permitiendo  a  los 
objetos  definirse  como  especializaciones  de  otros,  que  pueden 
compartir  y  extender  su  funcionalidad  sin  tener  que  reimplemen- 
tarlo  de  nuevo.  Esto  suele  hacerse  agrupando  los  objetos  en  cla¬ 
ses,  y  definiendo  otras  clases  como  extensiones  de  éstas,  creando 
árboles  de  clases. 


También  puede  decirse  que  la  definición  de  la  orientación  a  objetos 
proviene  del  "objeto  gramatical"  de  una  acción.  Veamos  algunos 
ejemplos  de  cómo  una  funcionalidad  se  expresa  de  forma  diferente 
en  programación  estructurada  (orientada  al  sujeto)  o  en  programa¬ 
ción  orientada  a  objetos: 


•  Orientada  al  sujeto:  la  aplicación  de  ventas  guarda  la  transacción. 


•  Orientada  al  objeto:  la  transacción  se  salva  a  partir  de  un  men¬ 
saje  de  la  aplicación  de  ventas. 


•  Orientada  al  sujeto:  la  aplicación  de  ventas  imprime  la  factura. 


•  Orientada  al  objeto:  la  factura  se  imprime  a  partir  de  un  mensaje 
de  la  aplicación  de  ventas. 


Como  vemos,  estamos  asociando  la  acción  al  objeto  al  que  afecta, 
no  a  quien  la  inicia  o  la  pide. 
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2.3.2.  Historia 


El  concepto  de  "objeto"  en  programación  apareció  en  1967  cuando 
se  presentó  el  lenguaje  Simula'67  diseñado  para  programar  simula¬ 
ciones.  La  idea  de  agrupar  datos  y  funcionalidad  en  una  única  es¬ 
tructura  se  originó  en  respuesta  a  la  complejidad  de  representar 
todas  las  combinaciones  de  diferentes  atributos  que  los  elementos 
participantes  en  una  simulación  podían  presentar.  Más  adelante,  lle¬ 
gó  SmallTalk  como  un  refinamiento  del  mismo  concepto  desarrolla¬ 
do  en  el  XeroxPARC  que  permitía  la  creación  y  uso  de  objetos  en 
tiempo  de  ejecución. 

Pero  la  popularización  del  paradigma  tuvo  lugar  durante  la  década 
de  los  ochenta  con  la  llegada  de  C  +  -I-,  una  extensión  del  lenguaje 
C.  Y  su  consolidación  llegó  con  el  éxito  de  las  interfaces  de  usuario 
gráficas,  a  las  que  este  paradigma  se  ajusta  perfectamente. 

Desde  entonces,  características  de  la  orientación  a  objetos  se  han  aña¬ 
dido  a  lenguajes  de  programación  ya  existentes  como  Ada,  BASIC, 
Lisp,  Perl,  etc.,  lo  que  comportó  problemas  de  incompatibilidad  y 
dificultades  en  el  mantenimiento  de  código.  Por  el  contrario,  a  los  len¬ 
guajes  orientados  a  objeto  "puros"  les  faltaban  prestaciones  a  las  que 
los  programadores  se  habían  acostumbrado. 

En  las  últimas  décadas,  el  lenguaje  Java  ha  tenido  un  gran  éxito  no 
sólo  por  su  implementación  muy  sólida  del  paradigma,  también  por 
su  parecido  a  C  y  C  +  -I-  y  por  el  uso  de  una  máquina  virtual  que  per¬ 
mitía  la  ejecución  de  código  en  múltiples  plataformas.  La  iniciativa 
.NET  de  Microsoft  es  parecida  en  este  aspecto  soportando  también 
varios  lenguajes  de  programación  tanto  de  nueva  creación  como  va¬ 
riantes  de  lenguajes  ya  existentes. 

Más  recientemente,  han  aparecido  lenguajes  que  son  principalmente 
orientados  a  objetos  pero  compatibles  con  metodologías  estructura¬ 
les  como  PHP,  Python  y  Ruby. 

De  la  misma  forma  que  la  programación  procedural  evolucionó  ha¬ 
cia  la  programación  estructurada,  la  orientación  a  objetos  ha  ido  in¬ 
corporando  mejoras  como  los  patrones  de  diseño  y  los  lenguajes  de 
modelado  como  UML. 
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2.3.3.  Clases  v  objetos 


Como  se  ha  comentado  en  apartados  anteriores,  todo  objeto  es  ins¬ 
tancia  de  una  clase,  entiendo  ésta  como  la  abstracción  de  un  "tipo" 
de  datos  dentro  del  espacio  del  problema  que  queremos  resolver. 

Ya  que  una  clase  describe  un  conjunto  de  objetos  que  tienen  carac¬ 
terísticas  idénticas  (elementos  de  datos  o  atributos)  y  comportamien¬ 
tos  idénticos  (funcionalidades  o  métodos),  una  clase  es  un  tipo  de 
datos  a  todos  los  efectos.  Cada  objeto  de  la  clase  dentro  de  nuestro 
programa  tendrá  unos  valores  concretos  para  sus  datos  (de  ahí  que 
llamemos  "instancia"  al  objeto  de  la  clase).  Una  vez  definida  la  clase 
que  representa  un  elemento  de  nuestro  problema,  podremos  crear 
tantos  objetos  de  ella  como  queramos  y  manipularlos  para  que  se 
comporten  como  deben  hacerlo  en  el  problema  que  estamos  resol¬ 
viendo. 


Cada  objeto  va  a  satisfacer  o  aceptar  un  cierto  tipo  de  peticiones,  se¬ 
gún  sea  su  cometido  o  responsabilidad  en  el  problema.  Las  peticio¬ 
nes  que  podemos  hacer  a  un  objeto  se  definen  en  su  "interfaz".  Los 
atributos  propios  del  objeto  ¡unto  con  el  código  que  satisface  esas 
peticiones  es  su  "implementación". 


Figura  1 .  Representación 
gráfica  de  una  clase 


El  nombre  de  la  clase  es  "Estudiante",  los  atributos  del  mismo  son  su 
"nombre",  "apellidos",  "dirección"  y  "teléfono"  y  las  peticiones  que 
podemos  hacerle  son  "matrícula",  "nota"  y  "enviarMensaje". 


Nota 


Esta  figura  sigue  la  notación 
definida  en  el  Lenguaje  Uni¬ 
ficado  de  Modelado  (UML), 
en  el  que  la  dase  se  repre¬ 
senta  mediante  una  caja  divi¬ 
dida  en  tres  zonas.  El  nombre 
se  representa  en  la  parte  su¬ 
perior,  los  datos  o  atributos 
que  deseemos  mostrar  en  su 
parte  central  y  las  peticiones 
o  métodos  públicos  en  su 
parte  inferior. 


67 


En  el  momento  de  desarrollar  o  entender  un  problema  que  vamos  a 
solucionar  con  orientación  a  objetos,  suele  ser  útil  pensar  en  los  ob¬ 
jetos  en  términos  de  "proveedores  de  servicios".  Nuestro  programa 
va  a  prestar  servicios  a  los  usuarios,  y  lo  va  a  hacer  utilizando  servi¬ 
cios  que  presten  los  objetos.  El  objetivo  es  crear  (o  reutilizar)  los  ob¬ 
jetos  que  proporcionen  los  servicios  más  ajustados  a  las  necesidades 
del  problema. 


Siguiendo  con  el  ejemplo  del  estudiante,  si  queremos  que  nuestro 
programa  imprima  su  expediente  imaginaremos  un  objeto  "estu¬ 
diante"  similar  al  anterior,  un  objeto  que  calculará  su  expediente  y 
un  objeto  que  creará  el  informe  con  el  formato  adecuado  para  im¬ 
primirlo  (quizá  mediante  otro  objeto). 


Al  pensar  de  esta  forma,  inconscientemente  estamos  creando  un  siste¬ 
ma  bien  cohesionado.  Esto  es  fundamental  en  la  calidad  del  diseño  del 
software,  significa  que  los  objetos  (y  sus  interfaces)  encajan  bien  unos 
con  otros.  En  un  buen  diseño  orientado  a  objeto,  cada  uno  hace  una 
cosa  bien,  y  no  intenta  hacer  demasiado.  En  el  ejemplo,  probablemen¬ 
te  descubriríamos  que  el  objeto  que  nos  proveerá  el  servicio  de  impre¬ 
sión  tendremos  que  dividirlo  para  poder  proveer  servicios  de  impresión 
genéricos,  comunicarse  con  modelos  específicos  de  impresoras,  etc. 
También  este  ejercicio  es  útil  para  identificar  objetos  susceptibles  de 
ser  reutilizados  o  de  que  los  encontremos  ya  desarrollados  en  catá¬ 
logos  públicos  de  objetos. 


2.3.4.  Encapsulación 

Al  diseñar  los  objetos  de  nuestra  aplicación,  necesitamos  tener  en 
cuenta  los  tipos  de  consumidores  de  los  mismos.  Por  una  parte  ten¬ 
dremos  a  los  programadores  que  van  a  poder  crear  clases  (creado¬ 
res  de  clases),  y  por  la  otra  a  los  que  sólo  van  a  usarlas  en  la  misma 
u  otras  aplicaciones  (consumidores  de  clases). 


Los  programadores  consumidores  de  clases  buscarán  disponer  de 
unas  herramientas  en  forma  de  objetos  para  desarrollar  rápidamen¬ 
te  nuevas  funcionalidades  o  nuevas  aplicaciones  a  partir  de  nuestras 
clases,  mientras  que  el  objetivo  de  los  creadores  de  clases  será 
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construirlas  de  forma  que  sólo  sea  visible  su  interfaz  a  los  consumidores 
de  clases  y  el  resto  esté  oculto. 


El  motivo  es  que  construyendo  las  clases  de  esta  forma,  el  creador  de 
la  clase  podrá  cambiar  su  implementación  sin  preocuparse  del  im¬ 
pacto  que  estos  cambios  tienen  en  los  consumidores  de  la  clase,  re¬ 
duciendo  así  los  posibles  fallos  de  integración.  Estamos  evitando  que 
los  programadores  consumidores  de  nuestras  clases  toquen  partes 
de  las  mismas  que  son  necesarias  para  el  funcionamiento  interno, 
pero  que  no  forman  parte  de  la  interfaz  de  la  clase.  Estamos  además 
facilitando  su  tarea,  ya  que  sólo  deberán  concentrarse  en  lo  que  van 
a  usar  sin  tener  que  preocuparse  de  cómo  está  hecho. 


Figura  2.  Representación  gráfica  de  los  elementos 
que  componen  una  clase 


La  encapsulación  es  la  propiedad  de  las  clases  y  los  mecanismos  que 
tendremos  en  cada  lenguaje  de  programación  que  nos  permite  de¬ 
finir  qué  métodos  o  atributos  son  públicos,  privados  o  tienen  algún 
otros  mecanismo  de  protección.  Separando  la  interfaz  pública  de  la 
implementación  interna  (privada)  facilitaremos  también  las  tareas  de 
reescritura  de  procesos  internos  de  la  clase  (para  mejorar  su  rendi¬ 
miento,  por  ejemplo). 
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Nota 


Esta  figura  sigue  la  notación 
definida  en  el  Lenguaje  Uni¬ 
ficado  de  Modelado  (UML), 
en  el  que  la  composición  se 
representa  mediante  el  dia¬ 
mante  sólido.  La  agregación 
se  representaría  mediante  la 
silueta  del  diamante. 


2.3.5.  Reusando  la  implementación.  Composición 

Una  vez  tenemos  una  clase  desarrollada  y  probada,  debería  repre¬ 
sentar  un  elemento  de  código  útil  en  sí  mismo.  No  siempre  es  así,  y 
se  necesita  experiencia  e  intuición  para  producir  clases  fácilmente 
reutilizables.  La  forma  más  simple  de  utilizar  una  clase  es  instanciar 
un  objeto  de  la  misma,  pero  también  podemos  poner  esa  clase  den¬ 
tro  de  otra,  creando  lo  que  se  llama  un  "objeto  miembro"  de  la  nue¬ 
va  clase.  Esta  nueva  clase  puede  estar  formada  por  tantos  objetos 
como  queramos  y  en  cualquier  combinación  destinada  a  solucionar 
el  problema  al  que  nos  estamos  enfrentando. 

Ya  que  estamos  componiendo  una  nueva  clase  a  partir  de  otras  ya 
existentes,  este  concepto  se  llama  "composición"  (si  la  composición 
ocurre  dinámicamente,  suele  llamarse  "agregación").  La  composi¬ 
ción  suele  referirse  a  relaciones  del  tipo  "tiene-un",  como  por  ejem¬ 
plo  "un  alumno  tiene  un  expediente". 


Figura  3.  Representación  gráfica  de  una  composición 


Típicamente,  los  objetos  miembro  de  la  nueva  clase  son  de  acceso  pri¬ 
vado.  Esto  permitirá  al  programador  de  la  misma  cambiarlos  por  otros 
si  es  necesario  sin  cambiar  otras  partes  del  código  o  instanciarlos  en 
tiempo  de  ejecución  para  cambiar  el  comportamiento  de  la  clase. 


2.3.6.  Reusando  la  interfaz.  Herencia 


Una  de  las  más  conocidas  características  de  la  orientación  a  objetos 
es  la  posibilidad  de  escoger  una  clase  existente,  crear  una  copia  y 
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después  añadir  o  modificar  sus  prestaciones  en  la  copia  creada.  Esto 
es  lo  que  se  entiende  por  herencia  en  este  paradigma,  con  la  carac¬ 
terística  adicional  de  que  si  la  clase  original  (llamada  la  clase  base, 
superclase  o  clase  padre)  cambia,  también  cambiará  su  copia  (lla¬ 
mada  la  clase  derivada,  heredada,  subclase  o  clase  hija). 


Figura  4.  Representación  gráfica 
de  la  herencia 


Nota 


La  flecha  de  este  diagrama 
UML  apunta  de  la  clase  de¬ 
rivada  a  la  superclase. 


Cuando  heredamos  de  una  clase  base,  estamos  creando  un  nuevo 
tipo.  Este  nuevo  tipo  no  sólo  tiene  todos  los  atributos  y  métodos  de 
la  clase  padre  (aunque  los  que  eran  ocultos  seguirán  siéndolo), 
sino  que  duplica  completamente  su  interfaz.  Es  decir,  todos  los 
mensajes  que  podíamos  mandar  a  un  "UsuarioCampus",  los  pode¬ 
mos  mandar  a  un  "Estudiante",  y  como  la  clase  viene  determinada 
por  la  interfaz,  deducimos  que  un  "Estudiante"  es  también  un 
"UsuarioCampus". 


Ahora  bien,  la  clase  "Estudiante"  se  ha  diferenciado  de  la  clase 
"UsuarioCampus",  ha  añadido  nuevas  propiedades  y  métodos 
que  "UsuarioCampus"  no  tenía,  en  otras  palabras,  hemos  "exten¬ 
dido"  la  clase  "UsuarioCampus". 
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En  diseño  orientado  a  objetos,  siempre  debemos  estar  dispuestos  a  re¬ 
estructurar  nuestras  clases,  y  precisamente  gracias  a  las  propiedades 
de  encapsulación  y  abstracción,  este  rediseño  no  comportará  muchos 
cambios  en  el  código.  Veamos  la  siguiente  situación: 


A  primera  vista,  vemos  que  todas  las  clases  que  heredan  de  "Usua- 
rioCampus"  comparten  algunos  atributos  y  métodos,  además,  con¬ 
ceptualmente,  estos  atributos  también  tienen  sentido  para  un 
"UsuarioCampus".  Así  pues,  lo  más  natural  sería  situar  estos  atribu¬ 
tos  y  métodos  en  la  superclase. 
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Ahora  nos  podríamos  plantear  si  tiene  sentido  mantener  la  clase 
"Consultor"  o  bien  ésta  ya  no  es  necesaria.  Y  aquí  es  donde  aparece 
la  otra  forma  de  diferenciación  de  la  superclase.  Para  un  "Consul¬ 
tor",  los  métodos  entraCampus  ( )  y  saleCampusO  realizarán 
operaciones  diferentes  que  para  un  "Estudiante"  (quedará  registrado 
su  acceso  en  estadísticas  diferentes,  etc.)  por  lo  que  en  lugar  de  aña¬ 
dir  funcionalidad  de  "UsuarioCampus"  lo  que  hace  "Consultor"  es 
modificar  funcionalidad  existente  (sobreescribir  una  funcionalidad). 


Por  lo  que  hemos  visto  hasta  ahora,  la  herencia  nos  permite  crear  re¬ 
laciones  del  tipo  "es-un"  y  del  tipo  "es-como"  según  estemos  so¬ 
breescribiendo  o  extendiendo  funcionalidades  respectivamente. 


2.3.7.  Polimorfismo 

Al  trabajar  con  jerarquías  de  clases  de  este  tipo,  nos  daremos  cuenta 
de  que  a  veces  vamos  a  querer  trabajar  con  la  clase  derivada  como 
si  fuese  la  superclase.  Esto  nos  permitirá  escribir  código  que  hable 
con  "UsuarioCampus"  y  afecte  a  "Estudiante"  o  "Consultor"  sin  tener 
que  escribir  código  para  cada  uno. 
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Si  más  adelante  extendemos  aún  más  la  clase  "UsuarioCampus", 
tampoco  tendremos  que  cambiar  nuestro  código.  Esto  provoca  lo 
que  se  llama  en  términos  de  compilación  el  late  binding.  El  compi¬ 
lador  no  sabe  a  qué  clase  estaremos  llamando  en  tiempo  de  ejecu¬ 
ción,  sólo  puede  comprobar  que  los  parámetros  de  la  llamada 
sean  correctos,  pero  no  sabe  exactamente  qué  código  ejecutará. 


Ya  hemos  comentado  que  la  implementación  del  método 
entraCampus  ( )  será  diferente  para  "Consultor"  y  para  "Estudian¬ 
te",  pero  el  objeto  que  llame  a  este  método  lo  hará  sobre  un  objeto 
de  la  clase  "UsuarioCampus"  (ya  que  tanto  "Consultor"  como  "Estu¬ 
diante"  lo  son). 


Supongamos  que  tenemos  un  código  que  trabaja  con  UsuarioCampus, 
de  esta  forma: 


void  trabajaüsuarios (UsuarioCampus  uc)  { 
uc . entraCampus ( ) ; 


uc . cambiarContraseña  ( ) ; 
uc . saleCampus ( ) ; 


Este  código  habla  con  cualquier  "UsuarioCampus",  por  lo  tanto,  es 
independiente  del  tipo  específico  de  usuario.  Si  en  otra  parte  del  pro¬ 
grama  usamos  este  método, 


Consultor  co  =  new  Consultor!)  ; 
Estudiante  es  =  new  Estudiante!); 
trabajaüsuarios (co) ; 
trabajaüsuarios (es) ; 


estas  llamadas  son  perfectamente  lógicas.  Lo  que  está  sucediendo 
es  que  un  "Consultor"  se  está  pasando  como  parámetro  a  un  mé¬ 
todo  que  espera  un  "UsuarioCampus",  pero  como  un  "Consultor"  es  un 
"UsuarioCampus",  puede  ser  tratado  como  tal  por  trabajaüsuarios  () . 
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El  proceso  de  tratar  a  una  clase  derivada  como  la  clase  base  suele 
llamarse  upcasting,  por  el  significado  de  hacer  un  casi  (cambiar  el 
tipo  de  una  variable  o  objeto)  hacia  arriba  en  la  jerarquía  de  objetos: 


Figura  7.  Camino  que  sigue  la  conversión  de  clases 
en  un  upcasting 


De  la  misma  forma,  vemos  que  el  código  de  la  función  trabaj  aUsua- 
rios  ()  no  contempla  todos  los  tipos  de  "UsuarioCampus",  sino  que 
llama  directamente  al  método  e  internamente  sucede  lo  correcto.  Tanto 
si  "Consultor"  o  "Estudiante"  han  sobreescrito  ese  método  en  particular 
como  si  no,  se  llama  al  método  apropiado.  Esto  es  polimorfismo  en  el 
sentido  de  que  las  clases  pueden  actuar  tanto  como  sus  derivadas  o 
como  sus  clases  base  según  las  circunstancias  en  que  se  encuentren 
o  los  mensajes  que  reciban. 


2.3.8.  Superclases  abstractas  e  interfaces 

En  algunas  ocasiones,  nos  puede  interesar  que  la  superclase  repre¬ 
sente  únicamente  una  interfaz  para  sus  clases  derivadas.  Es  decir,  no 
queremos  que  nadie  instancie  un  objeto  de  la  superclase,  sólo  nece¬ 
sitaremos  que  hagan  upcasting  para  usar  su  interfaz.  Esto  es  lo  que 
se  llama  definir  una  clase  "abstracta".  De  la  misma  forma,  un  méto¬ 
do  definido  en  una  superclase  puede  ser  abstracto  en  el  sentido  de 
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que  esa  superclase  no  lo  implemente  y  deberemos  sobreescribirlo 
añadiéndole  código  en  cada  clase  derivada. 


Si  una  clase  tiene  métodos  abstractos,  ya  es  una  clase  abstracta.  Si  to¬ 
dos  los  métodos  son  abstractos,  entonces  habremos  separado  total¬ 
mente  la  implementación  de  la  interfaz  y  tendremos  una  superclase 
"interfaz".  Pensemos  por  ejemplo  en  una  clase  que  represente  a  las 
impresoras  de  nuestro  sistema.  Esta  clase  tendrá  métodos  para  impri¬ 
mir,  modificar  los  márgenes,  etc.  pero  no  tendrá  implementación. 
Para  cada  impresora  de  nuestro  sistema  deberemos  crear  una  clase 
hija  que  implemente  estos  métodos  en  cada  modelo  de  impresora. 


Nota 


La  flecha  discontinua  de  este 
diagrama  UML  apunta  des¬ 
de  la  clase  que  im-plementa 
la  interfaz  hacia  la  clase  de¬ 
finida  como  interfaz. 


Figura  8.  Representación  gráfica 
de  la  implementación  de  una  interfaz 


2.3.9.  La  orientación  a  objetos  v  la  notación  UML 

En  paralelo  a  los  avances  en  paradigmas  de  programación,  también 
han  evolucionado  los  métodos  y  notaciones  para  modelar  y  diseñar 
los  sistemas  antes  de  implementarlos.  La  orientación  a  objetos  no  es 
una  excepción  y  la  forma  de  presentar  la  solución  al  problema  plan¬ 
teado  en  forma  de  objetos  que  representan  las  entidades  involucra¬ 
das  es  muy  susceptible  de  ser  modelada  de  forma  visual,  es  decir, 
mediante  diagramas  muy  fácilmente  entendióles. 

El  Dr.  James  Rumbaugh  fue  uno  de  los  pioneros  en  técnicas  de  mo¬ 
delado  de  clases,  jerarquías  y  modelos  funcionales,  que  según  él 
"capturaban  las  partes  esenciales  de  un  sistema". 
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El  modelado  visual  de  un  sistema  nos  permitirá  lo  siguiente: 

1 )  Identificar  y  capturar  los  procesos  de  negocio. 

2)  Disponer  de  una  herramienta  de  comunicación  entre  los  analistas  de 
la  aplicación  y  los  conocedores  de  las  reglas  de  negocio. 

3)  Expresar  la  complejidad  de  un  sistema  de  forma  entendióle. 

4)  Definir  la  arquitectura  del  software,  sus  componentes  implicados  (in¬ 
terfaz  de  usuario,  servidor  de  bases  de  datos,  lógica  de  negocio)  inde¬ 
pendientemente  del  lenguaje  de  implementación  que  usemos. 

5)  Promover  la  reutilización,  al  identificar  más  fácilmente  los  sistemas 
implicados  y  los  componentes. 

Así  pues,  a  partir  de  técnicas  desarrolladas  por  James  Rumbaugh  en 
modelado  de  objetos,  Ivar  Jacobson  en  casos  de  uso,  Grady  Booch 
en  su  metodología  de  descripción  de  objetos  y  con  la  participación 
de  empresas  como  HP,  IBM,  Oracle  y  Microsoft  entre  otras,  se  creó 
la  notación  UML  bajo  el  patrocinio  de  la  empresa  Rational  (recien¬ 
temente  adquirida  por  IBM)  y  fue  aprobada  por  la  OMG  (Object 
Management  Group)  en  1997. 

Las  siglas  UML  son  la  abreviatura  de  Unlfled  Modeling  Language 
(Lenguaje  Unificado  de  Modelado)  y  combina  en  una  sola  notación 
los  siguientes  modelos: 

•  Modelado  de  datos  (similar  a  un  diagrama  entidad  relación). 

•  Modelado  de  reglas  de  negocio  y  flujos  de  trabajo. 

•  Modelado  de  objetos. 

•  Modelado  de  componentes  de  un  sistema. 

En  pocos  años  se  ha  convertido  en  el  estándar  para  visualizar,  espe¬ 
cificar,  construir  y  documentar  los  elementos  que  intervienen  en  un 
sistema  software  de  cualquier  tamaño.  Puede  usarse  en  cualquier 
proceso,  durante  todo  el  ciclo  de  vida  del  proyecto  e  independiente¬ 
mente  de  la  implementación. 
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Hay  que  tener  en  cuenta  que  UML  no  es  una  metodología,  es  simple¬ 
mente  una  notación  para  modelar  nuestro  sistema.  Por  ello,  tampo¬ 
co  está  pensado  para  describir  la  documentación  de  usuario,  ni 
siquiera  su  interfaz  gráfica.  Así  pues,  al  empezar  un  proyecto  software, 
deberemos  primero  escoger  la  metodología  bajo  la  que  vamos  a  tra¬ 
bajar  con  él,  para  después  usar  UML  a  lo  largo  del  ciclo  de  vida  que 
nos  marque  la  metodología  escogida.  UML  tampoco  recomienda 
ninguna  en  concreto,  aunque  quizá  el  método  iterativo  visto  en  el  ca¬ 
pítulo  anterior  es  el  más  usado  y  el  que  mejor  se  adapta  a  los  pro¬ 
yectos  diseñados  con  el  paradigma  de  orientación  a  objetos  y 
modelados  en  UML. 

UML  ha  sido  y  seguirá  siendo  el  estándar  de  modelado  orientado  a 
objetos  de  los  próximos  años,  tanto  por  la  aprobación  de  los  exper¬ 
tos  en  metodologías  e  ingeniería  del  software,  como  por  la  participa¬ 
ción  de  las  grandes  empresas  de  software,  la  aceptación  del  OMG 
como  notación  estándar  y  la  cantidad  de  herramientas  de  modelado 
que  lo  soportan. 


2.3.10.  introducción  a  UML 

Un  modelo  es  una  abstracción  de  un  sistema  o  de  un  problema  que 
hay  que  resolver,  considerando  un  cierto  propósito  o  un  punto  de 
vista  determinado.  El  modelo  debe  describir  completamente  los  as¬ 
pectos  del  sistema  que  son  relevantes  a  su  propósito  y  bajo  un  de¬ 
terminado  nivel  de  detalle. 


El  código  fuente  es  también  una  expresión  del  modelo,  la  más  de¬ 
tallada  y  la  que  además  implemento  la  funcionalidad  del  mismo, 
pero  no  es  cómodo  como  herramienta  de  comunicación.  Además, 
para  llegar  a  él  es  conveniente  desarrollar  antes  otras  represen¬ 
taciones. 


Un  diagrama  nos  permitirá  representar  gráficamente  un  conjunto  de 
elementos  del  modelo,  a  veces  como  un  grafo  con  vértices  conecta¬ 
dos,  y  otras  veces  como  secuencias  de  figuras  conectadas  que  repre¬ 
senten  un  flujo  de  trabajo. 
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Figura  9.  Diagramas  UML  de  representación  de  los  modelos 

de  un  sistema 


Cada  punto  de  vista  del  sistema  (y  cada  nivel  de  detalle)  podrá  mo¬ 
delarse  y  ese  modelo  podrá  representarse  gráficamente.  Lo  que  UML 
propone  es  una  notación  y  un  conjunto  de  diagramas  que  abarcan 
las  perspectivas  más  relevantes  del  sistema. 


•  Diagrama  de  casos  de  uso 

•  Diagrama  de  clases 

•  Diagramas  de  comportamiento 

-  Diagrama  de  estados 

-  Diagrama  de  actividad 

-  Diagramas  de  interacción 

Diagrama  de  secuencia 
Diagrama  de  colaboración 

•  Diagramas  de  implementación 

-  Diagrama  de  componentes 

-  Diagrama  de  despliegue 

Estos  diagramas  responden  a  las  vistas  de  un  sistema  software.  Des¬ 
de  la  definición  del  problema  (casos  de  uso),  la  vista  lógica  (clases, 
objetos),  la  vista  de  procesos  (comportamiento)  y  la  vista  de  imple- 
mentación  y  distribución. 
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La  última  especificación  de  UML  disponible  es  la  revisión  1 .5  y  la  ver¬ 
sión  2.0  está  en  su  última  fase  de  revisión  que  terminará  durante  el 
año  2005  e  incorpora  conceptos  como  la  descripción  de  infraestruc¬ 
turas,  el  intercambio  de  diagramas  y  la  expresión  de  restricciones  en 
objetos  ( constraints ). 


Existen  multitud  de  herramientas  de  soporte  a  la  creación  de  diagra¬ 
mas  UML.  A  lo  largo  de  los  siguientes  capítulos  mostraremos  las  más 
representativas  con  licencia  de  código  abierto  y  los  diagramas  que 
presentaremos  estarán  hechos  con  esas  herramientas  para  mostrar 
mejor  al  estudiante  sus  posibilidades  y  diferencias.  Las  herramientas 
que  utilizaremos  son  Dia,  Umbrello  y  ArgoUML. 


2.3.1 1 .  Conclusiones 


Lectura  recomendada 


Para  profundizar  en  este 
paradigma  o  adquirir  expe¬ 
riencia  en  programación 
orientada  a  objeto  os  reco¬ 
mendamos  que  consultéis 
los  textos  siguientes: 

B.  Eckel  (2003).  Thinking 
in  Java  (3. 9  ed.).  Upper 
Saddle  River:  Prentice  Hall. 
http://www.mindview.net/ 
Books/TIJ/ 

Java  Technology. 
http://java.sun.com 

E.  Gamma;  R.  Helm  y  otros 
(1995).  Design  Patterns. 
Reading,  Mass:  Addison 
Wesley. 

Object  Management  Group. 
http://www.omg.org/ 


En  este  apartado  hemos  hecho  un  rápido  repaso  por  los  conceptos 
relacionados  con  el  paradigma  de  la  orientación  a  objetos.  Hemos 
intentado  describir  sus  características  más  importantes  y  proporcio¬ 
nar  ejemplos  ilustrativos,  a  la  vez  que  hemos  introducido  algunos 
elementos  de  la  notación  UML  que  veremos  en  detalle  en  apartados 
posteriores. 


También  hemos  introducido  la  notación  UML,  su  historia  y  sus  carac¬ 
terísticas  principales. 


2.4.  Definición  del  caso  práctico 


Para  entender  una  notación  de  modelado  como  UML,  podríamos  sim¬ 
plemente  leer  la  especificación  que  publica  la  OMG  y  tendríamos  la 
visión  más  completa  posible  del  mismo.  Pero  tratándose  de  un  están¬ 
dar  que  indica  cómo  debemos  modelar  un  sistema,  es  mucho  más  có¬ 
modo  y  fácil  de  entender  haciéndolo  a  través  de  un  caso  práctico  en 
el  que  podamos  aplicar  cada  concepto  a  un  caso  concreto,  a  la  visión 
que  tienen  del  mismo  sus  participantes,  y  reflejar  en  un  diagrama  cada 
una  de  estas  visiones  y  casos. 
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El  caso  práctico  que  planteamos  es  el  siguiente: 


Una  empresa  de  desarrollo  de  software  tiene  problemas  para  gestio¬ 
nar  sus  operaciones  con  los  clientes,  tanto  si  se  trata  de  futuros  clien¬ 
tes  a  los  que  ha  presentado  una  propuesta  (o  está  pendiente  de 
hacerlo),  como  si  se  trata  de  clientes  que  han  contratado  un  proyecto 
y  hay  que  hacer  su  seguimiento,  no  sólo  en  términos  de  tareas  pen¬ 
dientes,  horas  invertidas,  etc.  sino  también  en  términos  de  factura¬ 
ción,  importes  pendientes  de  pago,  etc. 

Para  ello,  podría  decidirse  por  implantar  un  ERP  basado  en  software 
libre  y  parametrizarlo  según  sus  necesidades,  pero  después  de  evaluar 
algunas  de  las  alternativas  existentes,  optó  por  desarrollar  un  sistema 
completo  de  gestión  de  proyectos  y  clientes  a  la  medida  de  su  método 
de  trabajo.  Además,  si  el  sistema  es  lo  suficientemente  flexible,  podrá 
liberarlo  bajo  alguna  licencia  aprobada  por  la  OSI  y  obtener  benefi¬ 
cios  prestando  soporte,  formación  y  actualizaciones  del  mismo. 

Es  obvio  que  no  vamos  a  describir  aquí  el  proyecto,  ya  que  ésta  es  la 
tarea  que  vamos  a  realizar  mediante  UML  en  los  apartados  posterio¬ 
res.  Simplemente  vamos  a  enumerar  algunas  de  sus  características 
más  representativas  para  tener  conceptos  y  casos  con  los  que  empe¬ 
zar  a  trabajar. 

El  sistema  de  gestión  deberá  permitir: 

1 )  Disponer  de  una  lista  completa  de  contactos  de  la  empresa.  Sean  és¬ 
tos  clientes,  posibles  clientes  o  proveedores. 

2)  Disponer  de  una  lista  completa  de  proyectos  en  los  que  está  traba¬ 
jando  la  empresa.  De  cada  proyecto  deberemos  disponer  de  informa¬ 
ción  sobre: 

•  El  cliente  al  que  hace  referencia. 

•  El  estado  actual  del  proyecto. 

•  La  estimación  que  se  hizo  en  su  momento  (el  presupuesto  que  se 
presentó  al  cliente). 


Las  tareas  que  implica  el  proyecto,  su  estado,  duración  estimada 
y  real. 
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•  Los  costes  que  ha  tenido  el  desarrollo  del  proyecto. 


3)  Disponer  de  una  lista  de  desarrolladores  que  podamos  asociar  a 
cada  proyecto.  Éstos  deberán  registrar  las  horas  trabajadas  en  cada  ta¬ 
rea,  sus  avances,  etc. 


4)  Disponer  de  informes  en  los  que  podamos  ver  qué  proyectos  se  han 
retrasado,  cuál  ha  sido  el  resultado  de  un  proyecto  respecto  a  su  plani¬ 
ficación  inicial,  etc. 


Con  estos  datos,  damos  por  planteado  el  caso  de  estudio.  No  entra 
dentro  de  los  objetivos  de  este  capítulo  su  resolución,  por  lo  que  la 
especificación  no  es  todo  lo  completa  que  debería  ser  en  la  realidad, 
aunque  suficiente  para  empezar  a  trabajar. 


Tal  como  hemos  comentado  en  apartados  anteriores,  es  funda¬ 
mental  determinar  la  metodología  que  vamos  a  usar  antes  de  em¬ 
pezar  el  proceso  de  modelado.  En  nuestro  caso,  al  ser  una 
empresa  de  desarrollo  de  software  moderna  y  con  una  clara  incli¬ 
nación  hacia  el  software  libre,  nuestro  método  de  desarrollo  y 
gestión  de  proyectos  se  ajusta  perfectamente  al  que  caracteriza  un 
ciclo  de  vida  de  tipo  iterativo. 
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Aunque  nos  centraremos  en  las  fases  de  toma  de  requisitos,  análisis 
y  diseño,  algunos  de  los  diagramas  se  basarán  en  modelos  de  las 
fases  de  implementación  e  implantación.  No  es  posible  establecer 
una  secuencia  perfecta  entre  los  diagramas,  ni  una  correspondencia 
total  con  las  diferentes  fases  del  ciclo  de  vida,  ya  que  dependiendo 
de  las  personas  involucradas  en  cada  fase  y  de  su  experiencia  y  co¬ 
nocimiento,  algunos  diagramas  pueden  quedar  completados  en  fa¬ 
ses  muy  tempranas  mientras  que  otros  van  a  estar  sometidos  a 
continuas  revisiones.  Teniendo  en  cuenta  esto,  una  posible  corres¬ 
pondencia  es  la  siguiente: 


Figura  1 1 .  Correspondencia  de  los  diagramas  UML  con  fases 
de  un  proyecto 


a 

Ifl 

Diseño 

Diagramas  de 
componentes 


Diagramas 
de  clases 


Diagramas 
de  estados 


Diagramas 
de  uso 


Diagramas 
de  secuencia 


Diagramas  de 
despliegue 


Diagramas  de 
colaboración 


Diagramas 
de  actividad 


Aunque  la  figura  muestra  algunos  de  los  diagramas  unidos  por  fle¬ 
chas,  casi  todos  ellos  tienen  relación  con  los  demás,  de  forma  que 
un  cambio  en  alguno  puede  afectar  a  muchos  otros.  Sólo  hemos 
indicado  las  correspondencias  más  evidentes,  aunque  es  de  espe¬ 
rar  que  un  cambio  en  un  caso  de  uso,  por  ejemplo,  conllevará 
cambios  en  muchos  otros  diagramas,  o  que  un  cambio  en  el 
diagrama  de  componentes  puede  afectar  a  los  diagramas  de  cla¬ 
ses  y  de  despliegue. 

Como  la  lectura  del  material  nos  impone  un  orden,  vamos  a  seguir, 
en  la  medida  de  lo  posible,  el  mismo  de  la  figura,  de  arriba  abajo  y 
de  izquierda  a  derecha,  avanzando  por  las  fases  del  proyecto. 


2.5.  Diagramas  de  casos  de  uso 

Los  casos  de  uso  son  una  herramienta  esencial  en  la  toma  de  requi¬ 
sitos  del  sistema.  Nos  permiten  expresar  gráficamente  las  relaciones 
entre  los  diferentes  usos  del  mismo  y  sus  participantes  o  actores.  El 
resultado  es  un  conjunto  de  diagramas  muy  fácilmente  entendibles 
tanto  por  el  cliente,  como  por  los  analistas  del  proyecto. 

No  definen  todos  los  requisitos  (por  ejemplo,  tipos  de  datos,  interfa¬ 
ces  externas,  rendimiento,  etc.)  pero  sí  que  representan  el  hilo  con¬ 
ductor  que  los  vincula  a  todos  con  los  actores  del  sistema. 

Se  componen  de  los  siguientes  elementos: 


•  Actores:  representan  los  roles  que  juegan  los  usuarios  u  otros  sis¬ 
temas  en  el  sistema  del  problema.  Identificar  a  los  actores  de  un 
caso  de  uso  pasa  por  averiguar  quién  está  involucrado  en  cada 
requisito  concreto,  quién  se  beneficiará  de  cada  funcionalidad  o 
quién  proveerá  o  usará  la  información. 


Figura  12 


Jefe  de  Participante 
proyecto 


•  Caso  de  uso:  son  las  acciones  que  pueden  tener  lugar  en  el  sis¬ 
tema  que  queremos  modelar.  Para  identificarlas,  puede  ser  útil 
preguntarse  cuáles  son  las  tareas  y  responsabilidades  de  cada  ac¬ 
tor,  si  habrá  actores  que  recibirán  información  del  sistema,  etc. 
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Relaciones:  indican  actividad  o  flujo  de  información. 


•  Límite  del  sistema:  define  el  ámbito  donde  se  produce  el  caso  de 
uso  que  estamos  representando  y  que  va  a  ser  tratado  por  el  sis¬ 
tema.  Los  actores  no  son  parte  del  sistema  y  por  lo  tanto  están 
fuera  de  sus  límites. 


A  continuación  veamos  una  propuesta  de  caso  de  uso  en  el  ámbito 
de  la  gestión  de  los  contactos  y  proyectos. 


Figura  14.  Caso  de  uso  para  la  gestión  de  contactos  y  proyectos. 
Realizado  con  Umbrello 


En  primer  lugar,  vemos  que  estamos  modelando  a  muy  alto  nivel, 
trasladando  lo  expresado  en  los  requerimientos  a  una  representa¬ 
ción  gráfica.  Las  relaciones  entre  los  actores  y  los  casos  de  uso  indi¬ 
can  si  proporcionan  o  reciben  información  (según  el  sentido  de  la 
flecha). 
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En  cambio,  las  relaciones  entre  casos  de  uso  pueden  tener  significa¬ 
dos  diferentes.  Cada  caso  de  uso  es  susceptible  de  representarse 
más  detalladamente  en  otro  diagrama.  Ampliemos  uno  de  ellos  para 
mostrarlo. 


Figura  15.  Caso  de  uso  para  la  aceptación  de  la  propuesta 


La  etiqueta  <  <incluye>  >  entre  dos  casos  de  uso  indica  que  uno  tie¬ 
ne  la  funcionalidad  de  otro  como  parte  integrante  suya.  En  el  ejem¬ 
plo,  la  aceptación  de  la  propuesta  incluirá  la  funcionalidad  para 
actualizar  los  datos  del  cliente  (ahora  tenemos  un  cliente  en  lugar  de 
un  simple  contacto),  emitir  la  factura  inicial,  quizá  (no  forzosamente) 
crear  el  proyecto,  etc. 

La  etiqueta  <<extiende>>  indicará  que  un  caso  de  uso  amplía  la 
funcionalidad  de  otro.  En  el  ejemplo,  la  emisión  de  la  factura  inicial 
no  es  la  emisión  de  una  factura  cualquiera,  implicará  comprobacio¬ 
nes,  como  por  ejemplo  si  tenemos  todos  los  datos  del  cliente,  etc., 
que  no  se  producen  en  la  emisión  de  una  factura  normal.  Ahora 
bien,  está  claro  que  habrá  una  parte  de  funcionalidad  que  compar¬ 
tirán.  En  otras  palabras,  la  creación  de  la  factura  inicial  es  un  caso 
particular  de  la  emisión  de  una  factura. 
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La  etiqueta  < <generaliza> >  indica  también  una  relación  padre- 
hijo  similar  a  la  extensión,  con  la  diferencia  de  que  actúan  exacta¬ 
mente  igual  en  cuanto  a  reglas  de  negocio  se  refiere.  En  otras  pala¬ 
bras,  en  un  momento  dado  podríamos  sustituir  el  caso  de  uso  padre 
por  el  hijo  y  el  sistema  no  se  vería  afectado.  En  cambio,  en  una  rela¬ 
ción  de  extensión  esto  no  sucede,  no  podemos  sustituir  la  emisión  de 
cualquier  factura  por  la  de  la  factura  inicial. 


Las  relaciones  de  generalización  también  pueden  darse  entre  los  ac¬ 
tores.  Volviendo  al  diagrama  inicial: 


Figura  1 6.  Caso  de  uso  para  la  gestión  de  contactos  y  proyectos, 
con  generalización  en  los  actores 


Vemos  que  generalizamos  a  un  cliente  en  un  contacto;  es  completa¬ 
mente  lógico  si  consideramos  que  todos  los  clientes  fueron  contactos 
en  un  cierto  instante  y  que  deben  poder  mantener  sus  mismas  fun¬ 
cionalidades. 
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Software  libre 


Dado  el  alto  nivel  al  que  estamos  modelando  el  sistema  en  esta  fase, 
es  importante  tener  presentes  algunas  buenas  prácticas  con  respecto 
a  la  interpretación  y  creación  de  diagramas  de  casos  de  uso: 


•  Empezar  los  nombres  de  los  casos  de  uso  con  un  verbo. 

•  Aunque  no  hay  forma  de  indicar  el  orden  en  que  un  actor  aplicará 
los  casos  de  uso,  suele  ser  más  intuitivo  representarlos  en  orden 
descendiente,  situando  los  más  importantes  en  la  parte  superior 
del  diagrama. 

•  Situar  a  los  actores  principales  en  la  parte  superior  del  diagrama 
también  ayuda  a  su  comprensión  y  a  generalizar  de  forma  más 
entendióle. 

•  Nombrar  a  los  actores  con  sustantivos  relacionados  con  las  reglas 
de  negocio,  de  acuerdo  con  los  roles  que  representan.  No  con  su 
cargo  o  posición  en  el  sistema. 

•  Anteponer  "Sistema"  o  <<sistema>>  a  los  actores  que  sean  pro¬ 
cesos  externos. 

•  Para  representar  eventos  que  ocurren  de  forma  programada,  po¬ 
demos  introducir  un  actor  de  sistema  "Tiempo"  para  modelar  sus 
casos  de  uso. 


•  La  etiqueta  <<incluye>>  no  es  obligatoria.  Es  aconsejable  in¬ 
cluirla  sólo  si  en  un  punto  específico  la  lógica  del  caso  de  uso  in¬ 
cluido  es  necesaria. 


•  No  debe  abusarse  de  la  etiqueta  <  <extiende>  >,  ya  que  dificulta 
la  comprensión  del  caso. 


•  La  generalización  de  clases  suele  identificarse  porque  una  sola 
condición  del  caso  de  uso  (en  el  ejemplo,  el  método  de  envío), 
cambia  por  completo  su  lógica  interna,  pero  no  así  las  reglas  de 
negocio  del  sistema. 
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•  Debe  evitarse  representar  más  de  dos  niveles  de  asociaciones  de 
casos  de  uso  en  un  mismo  diagrama.  Si  nos  encontramos  en  esta 
situación,  hay  muchas  probabilidades  de  que  estemos  haciendo 
una  representación  funcional  de  lo  que  ocurre  en  el  caso  de  uso. 
Debemos  concentrarnos  sólo  en  los  requisitos  de  uso,  ya  que  la 
descomposición  funcional  es  parte  de  la  fase  de  diseño. 

•  Situar  los  casos  incluidos  a  la  derecha  del  caso  que  los  incluye 
ayuda  a  comprender  mejor  el  diagrama.  De  la  misma  forma,  es 
más  intuitivo  situar  los  casos  que  extienden  debajo  del  caso  pa¬ 
dre,  al  igual  que  los  casos  que  heredan  o  generalizan. 

•  Es  útil  intentar  expresar  con  "es  como"  la  generalización  de  acto¬ 
res  para  comprobar  si  los  estamos  modelando  correctamente. 


2.6.  Diagramas  de  secuencia 

Los  diagramas  de  secuencia  modelan  el  flujo  de  la  lógica  dentro  del 
sistema  de  forma  visual,  permitiendo  documentarla  y  validarla.  Pue¬ 
den  usarse  tanto  en  análisis  como  en  diseño,  proporcionando  una 
buena  base  para  identificar  el  comportamiento  del  sistema. 

Típicamente  se  usan  para  modelar  los  escenarios  de  uso  del  sistema, 
describiendo  de  qué  formas  puede  usarse.  La  secuencia  puede  ex¬ 
presar  tanto  un  caso  de  uso  completo  como  quizá  un  caso  concreto 
del  mismo  contemplando  algunas  alternativas. 

También  son  una  buena  herramienta  para  explorar  la  lógica  de  una 
operación  compleja  o  los  elementos  implicados  en  la  prestación  de  un 
servicio.  Nos  pueden  ayudar  a  identificar  cuellos  de  botella  en  la  fase 
de  diseño,  detectar  cuáles  van  a  ser  las  clases  más  complejas  de  im- 
plementar  y  decidir  cuáles  de  ellas  van  a  necesitar  diagramas  de  esta¬ 
dos  (que  veremos  más  adelante)  para  facilitar  su  implementación. 

Se  componen  de  los  siguientes  elementos: 


Objeto:  instancia  de  una  clase  que  podemos  empezar  a  identifi¬ 
car  como  participante  en  la  secuencia  de  operaciones  que  repre¬ 
senta  este  caso  de  uso. 
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Figura  17 


•  Actor:  los  actores  pueden  comunicarse  con  los  objetos,  por  lo  tan¬ 
to  formarán  parte  de  este  diagrama. 


•  Vida  del  objeto:  indicamos  la  existencia  de  un  objeto  a  lo  largo 
del  tiempo  mediante  una  línea  discontinua.  El  fin  del  mismo  se  in¬ 
dica  mediante  un  aspa. 

•  Activación:  indicamos  cuándo  el  objeto  está  realizando  una  tarea 
concreta. 


Figura  18 


□ 


•  Mensaje:  la  comunicación  entre  objetos  y  sus  activaciones. 

A  continuación,  veamos  un  ejemplo  de  diagrama  de  secuencia  para 
el  caso  de  uso  implicado  en  cerrar  un  proyecto: 


Figura  1 9.  Diagrama  de  secuencia  para  el  caso  de  uso  "Cerrar 
un  proyecto".  Realizado  con  Dia 
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Una  de  las  características  de  los  diagramas  de  secuencia  es  que  casi 
no  necesitan  aclaraciones  en  cuanto  a  su  notación.  En  la  parte  supe¬ 
rior,  vemos  los  participantes  en  la  secuencia  (también  denominados 
"clasificadores"  que  implementan  la  misma).  En  general  siempre 
será  un  actor  el  que  inicie  la  secuencia,  y  el  resto  de  participantes 
pueden  ser  objetos  (representados  con  una  caja  en  la  que  escribire¬ 
mos  el  nombre  del  objeto),  otros  actores,  o  quizá  un  caso  de  uso 
completo. 


Cada  participante  tiene  un  intervalo  en  el  que  éste  está  activo  en  la 
secuencia,  que  se  indica  mediante  un  rectángulo  sobre  la  línea  dis¬ 
continua  que  representa  la  vida  del  objeto.  El  rectángulo  empieza 
cuando  el  objeto  recibe  un  mensaje  (representado  mediante  una  fle¬ 
cha  que  incorpora  el  nombre  de  la  llamada)  y  termina  cuando  éste 
devuelve  su  última  respuesta  (representada  mediante  una  flecha  dis¬ 
continua). 


Los  mensajes  suelen  incluir  números  de  secuencia  que  facilitan  la 
comprensión  del  diagrama  y  el  seguimiento  del  orden  en  que  se 
producen  los  mensajes.  A  veces  un  error  puede  provocar  una  línea 
discontinua  de  retorno  hasta  el  primer  participante,  de  forma  simi¬ 
lar  a  cómo  se  propagaría  una  excepción.  Así  pues,  las  líneas  de  re¬ 
torno  pueden  incluir  también  etiquetas  para  indicar  si  representan 
un  error  o  no. 


Finalmente,  un  aspa  al  final  de  la  vida  del  objeto  indica  que  éste  pue¬ 
de  destruirse. 


Según  la  notación,  es  posible  expresar  iteraciones  y  condicionales 
en  un  diagrama  de  secuencia.  Muchos  expertos  no  lo  recomien¬ 
dan,  ya  que  implica  incluir  lógica  dentro  de  un  diagrama  que  sólo 
debería  representar  mensajes  entre  participantes  en  la  secuencia, 
pero  a  veces  es  imprescindible  hacerlo  para  reflejar  correctamen¬ 
te  la  secuencia  de  mensajes.  Veamos  otro  ejemplo  a  partir  del 
caso  de  uso  relacionado  con  la  actualización  de  las  tareas  en  la 
gestión  de  proyectos. 
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Figura  20.  Diagrama  de  secuencia  correspondiente  a  la  gestión 
de  un  proyecto,  con  iteraciones  y  condiciones 


Las  guardas  de  las  condiciones  o  de  los  bucles  se  expresan  entre  cor¬ 
chetes.  Para  indicar  que  estamos  actuando  sobre  el  mismo  objeto, 
pintaremos  un  rectángulo  ligeramente  desplazado  a  la  derecha.  En 
general,  los  bucles  se  identificarán  por  el  texto  entre  corchetes,  que  in¬ 
dicará  sobre  qué  se  está  iterando  (p.  e¡.  "para  cada  tarea"),  mientras 
que  la  guarda  de  la  condición  deberá  ser  todo  lo  explícita  posible. 


En  caso  de  necesitar  una  acción  alternativa  ("participante! =creador" 
en  el  ejemplo),  cruzaremos  una  línea  sobre  otro  rectángulo  despla¬ 
zado  para  indicar  la  actividad  que  tendrá  lugar  si  no  se  cumple  la 
condición.  Puede  apreciarse  fácilmente  que  la  tendencia  a  introducir, 
lógica  compleja  dentro  de  los  diagramas  de  secuencia,  no  ayuda  a 
su  esclarecimiento,  más  bien  al  contrario.  La  versión  2.0  de  UML  in¬ 
troduce  el  concepto  de  los  "marcos  de  interacción"  que  ayudan  a 
mejorar  la  representación  en  estos  casos: 
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Los  marcos  de  interacción  se  representan  con  cajas  transparentes  que 
envuelven  la  condición  o  bucle.  En  la  esquina  superior  izquierda  se 
escribe  el  tipo  de  interacción  (bucle  o  condición),  y  en  la  línea  de  ac¬ 
tividad  del  objeto,  la  condición  entre  corchetes.  En  el  caso  de  condi¬ 
ciones  con  alternativa,  ésta  se  separa  mediante  una  línea  de  puntos. 


Cuando  este  tipo  de  diagramas  se  usan  en  fase  de  diseño,  se  suele  dis¬ 
poner  de  más  información  sobre  los  objetos  y  sus  mensajes.  Si  el  diagra¬ 
ma  se  realiza  en  esa  fase,  su  representación  puede  ser  más  completa: 


Figura  22.  Diagrama  de  secuencia  realizado  en  fase  de  diseño 
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Software  libre 


Los  mensajes  pueden  incluir  la  información  que  va  a  necesitar  el  ob¬ 
jeto  receptor  para  realizar  su  actividad.  También  hemos  incluido 
unas  notas  en  cada  secuencia  para  indicar  de  forma  textual  la  acti¬ 
vidad  que  representan. 


Finalmente,  enumeramos  un  conjunto  de  buenas  prácticas  en  la  re¬ 
presentación  de  diagramas  de  secuencia: 


•  El  orden  entre  los  mensajes  y  los  participantes  debe  ser  siempre 
de  izquierda  a  derecha  y  de  arriba  abajo  para  facilitar  la  com¬ 
prensión  del  diagrama. 


•  El  nombre  de  los  actores  debe  ser  consistente  con  los  casos  de 
uso. 


•  El  nombre  de  los  objetos  debe  ser  consistente  con  los  diagramas 
de  clases. 


•  Incluir  notas  en  las  secuencias. 


•  Sólo  incluir  el  aspa  de  destrucción  del  objeto  en  casos  en  que  pro¬ 
porcione  información  sobre  cuándo  debe  destruirse,  en  caso  con¬ 
trario  "ensuciaremos"  el  diagrama  innecesariamente. 


•  Si  la  secuencia  trabaja  con  varios  objetos  de  la  misma  clase  pero 
con  roles  diferentes,  podemos  etiquetarlos  de  la  manera  siguiente: 
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Vemos  que  tenemos  dos  instancias  del  objeto  Tarea,  una  para  la  ori¬ 
ginal  y  otra  para  la  copia. 


•  Usar  los  estereotipos  de  forma  consistente.  En  el  ejemplo  anterior, 
el  sistema  controlador  de  tareas  es  quien  inicia  la  clonación,  y  lo 
indicamos  mediante  la  palabra  <<sistema>>. 


•  En  los  parámetros  en  mensajes,  es  más  conveniente  usar  nombres 
claros  que  los  tipos  de  los  mismos. 


•  En  las  llamadas  a  casos  de  uso,  usar  el  estereotipo  <<incluye>>. 


2.7.  Diagramas  de  componentes 


El  desarrollo  orientado  a  objeto  está  muy  relacionado  con  el  desa¬ 
rrollo  basado  en  componentes,  en  el  sentido  de  que  las  clases  con 
sus  propiedades  de  encapsulación  y  abstracción  se  ven  en  muchas 
ocasiones  como  componentes  cerrados  de  un  sistema.  Así  pues,  la 
notación  UML  incluye  un  diagrama  de  componentes  que  según  la  de¬ 
finición  del  OMG  "muestra  las  dependencias  entre  componentes 
software,  incluyendo  los  clasificadores  que  los  especifican  (por  ejem¬ 
plo  las  clases  de  implementación)  y  los  artefactos  que  los  implemen- 
tan,  como  los  ficheros  fuente,  binarios,  Scripts,  etc.". 


En  muchos  casos  en  los  que  podrían  usarse  diagramas  de  compo¬ 
nentes,  se  usan  los  diagramas  de  despliegue  (que  veremos  más  ade¬ 
lante),  ya  que  éstos  nos  permiten  modelar  además  dónde  va  a 
implantarse  cada  componente  y  bajo  qué  configuración  o  paráme¬ 
tros.  Así  pues,  el  diagrama  de  componentes  ha  quedado  tradicional¬ 
mente  relegado  a  modelar  la  arquitectura  del  sistema  a  nivel  lógico 
o  de  entorno  de  negocio. 
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Aquí  hemos  modelado  la  estructura  de  los  componentes  software 
que  están  involucrados  en  la  aplicación  de  gestión  comercial.  Los 
componentes  incorporan  puertos  hacia  los  datos  o  servicios  que  pro¬ 
porcionan  (en  el  ejemplo  "contacto",  "agenda  comercial",  etc.)  o 
puertos  para  recibir  datos  o  resultados  de  peticiones. 


Cada  puerto  puede  tener  una  o  más  interfaces.  Ampliemos  un  com¬ 
ponente  para  mostrarlo  más  en  detalle: 
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Hemos  desarrollado  el  componente  "Cliente"  en  sus  partes  constitu¬ 
yentes  (clases,  muy  probablemente)  y  hemos  definido  sus  interfaces 
a  alto  nivel.  Vemos  que  básicamente  ofrece  interfaces  de  acceso  a 
sus  datos  (de  entrada  y  salida)  y  una  interfaz  de  exportación  de  datos 
de  facturación  para  comunicarse  con  la  aplicación  de  contabilidad. 
Aquí  hemos  utilizado  partes  de  la  notación  UML2.0,  que  diferencia 
entre  interfaces  que  el  componente  ofrece  (círculo  cerrado)  e  interfa¬ 
ces  que  el  componente  necesita  (círculo  abierto). 

Los  conceptos  de  interfaz  y  puerto  serán  muy  familiares  a  los  estu¬ 
diantes  que  tengan  experiencia  en  desarrollo  basado  en  componen¬ 
tes  (CORBA,  COM,  IDL,  etc.)  pero  en  la  mayoría  de  los  casos  no  será 
necesario  llegar  a  este  nivel  de  detalle  en  el  diagrama  en  aplicacio¬ 
nes  orientadas  a  objeto  convencionales. 

En  otros  entornos  donde  sea  habitual  utilizar  patrones  de  diseño,  los 
diferentes  objetos,  interfaces  y  la  comunicación  entre  ellos  se  pueden 
representar  en  los  detalles  del  componente. 

Finalmente,  la  lista  de  buenas  prácticas  en  la  representación  de  com¬ 
ponentes  es  la  siguiente: 

•  Aplicar  los  estereotipos  de  forma  consistente. 

•  Aunque  usemos  UML  1 .5,  la  representación  de  las  interfaces  de 
los  componentes  mediante  círculos  es  mucho  más  clara  que  una 
simple  flecha  entre  ellos. 


•  Ya  que  la  interfaz  es  un  conjunto  de  métodos,  intentemos  no  re¬ 
presentar  demasiadas  interfaces,  es  aconsejable  agruparlas  bajo 
un  mismo  nombre  y  crear  después  un  diagrama  detallado  del 
componente. 


•  Los  componentes  pueden  heredar  unos  de  otros.  En  este  caso,  la 
flecha  que  utilizamos  en  los  casos  de  uso  para  expresar  generali¬ 
zación  puede  servir  perfectamente. 


•  Para  mejorar  la  comprensión  de  un  diagrama  de  componentes, 
es  preferible  conectarlos  siempre  a  través  de  interfaces.  Es  más 
consistente  y  evita  confusiones  o  dudas  sobre  su  interpretación. 
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2.8.  Diagrama  de  actividades 


En  muchos  aspectos,  los  diagramas  de  actividades  son  el  equivalente 
orientado  a  objeto  de  los  diagramas  de  flujo  y  los  DFD  del  desarrollo 
estructurado.  Su  uso  es  principalmente  la  exploración  y  representa¬ 
ción  de  la  lógica  comprendida  en  operaciones  complejas,  reglas  de 
negocio,  casos  de  uso  o  procesos  software. 


De  forma  similar  a  los  tradicionales  diagramas  de  flujo,  todo  diagra¬ 
ma  de  actividades  tiene  un  punto  de  partida  y  un  final.  Las  activida¬ 
des  representarán  cada  paso  importante  que  se  produce  en  el 
proceso  que  estamos  modelando  (puede  representar  un  caso  de  uso 
o  bien  un  conjunto  de  ellos). 


Figura  26.  Diagrama  de  actividades. 
Representado  con  ArgoUML 


Las  transiciones  son  la  representación  del  flujo  de  información  o 
proceso  que  avanza  entre  actividades.  A  diferencia  de  los  diagra¬ 
mas  de  flujo,  el  diagrama  de  actividades  permite  modelar  acciones 
en  paralelo.  Para  dividir  el  proceso  o  bien  recuperar  un  único  flujo, 
se  utilizan  las  barras  de  sincronización  que  permiten  varios  flujos  de 
entrada  o  varios  de  salida. 
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Veamos  a  continuación  un  ejemplo  más  completo: 


Figura  27.  Diagrama  de  actividades  correspondiente 
a  la  creación  de  un  proyecto 


Puede  apreciarse  que  los  elementos  condicionales  son  similares  a  los 
de  los  diagramas  de  flujo:  un  rombo  con  las  transiciones  etiquetadas 
según  sea  el  resultado  de  la  condición  evaluada. 


Algunos  autores  consideran  una  buena  práctica  marcar  los  ámbitos 
de  actuación  de  clases  o  componentes  en  el  diagrama,  para  dar  más 
información  sin  añadir  complejidad.  Para  ello,  pueden  usarse  som¬ 
bras  bajo  los  objetos  o  bien  organizar  las  actividades  en  columnas 
etiquetadas. 
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Figura  28.  Diagrama  de  actividades  con  separación  del  ámbito 
en  que  se  producen 


El  diagrama  de  actividades,  al  incorporar  mecanismos  de  sincroni¬ 
zación,  permite  expresar  qué  actividades  se  pueden  realizar  en  pa¬ 
ralelo  y  cuáles  deben  realizarse  en  serie.  La  implementación  podría 
optar  por  no  paralelizar  todo  lo  posible,  pero  debemos  tener  presen¬ 
te  que  estamos  representando  el  modelo,  no  expresando  su  imple- 
mentación. 

También  es  muy  importante  representar  correctamente  la  sincroniza¬ 
ción  cuando  dos  o  más  flujos  de  actividad  convergen  en  un  punto.  En 
el  ejemplo  hemos  preferido  expresar  dos  actividades  "Proyecto  crea¬ 
do"  y  "Factura  creada"  para  evitar  sincronizar  todas  las  actividades 
finales  en  un  mismo  punto.  Es  un  concepto  que  clarifica  la  represen¬ 
tación  y  en  el  momento  de  la  implementación  no  va  a  afectar  a  la  ca¬ 
lidad  del  resultado,  ya  que  si  la  actividad  simplemente  devuelve  un 
valor  o  recoge  los  resultados  de  las  actividades  anteriores,  el  diagra¬ 
ma  seguirá  siendo  igual  de  correcto.  Si  además  se  realizan  tareas  de 
consolidación  de  datos,  liberación  de  objetos  etc.,  éstas  podrán  reali¬ 
zarse  también  en  paralelo. 

El  diagrama  de  actividades  de  UML  1 .5  no  va  más  allá.  En  UML  2.0  se 
añaden  un  buen  número  de  elementos  a  su  notación  para  expresar  el 
tiempo,  el  tipo  de  actividad  (una  simple  llamada,  una  transformación 
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de  datos,  la  transmisión  de  un  objeto  y  cuál),  o  la  representación  de 

eventos  externos  que  afectan  al  flujo  de  actividades. 

Finalmente,  veamos  algunas  buenas  prácticas  relacionadas  con  es¬ 
tos  diagramas: 

•  Situar  el  punto  de  inicio  en  la  parte  superior  del  diagrama. 

•  Aunque  algunos  autores  lo  consideran  opcional  (una  actividad 
puede  ser  el  final  del  diagrama),  siempre  es  conveniente  situar  un 
punto  de  final  de  la  actividad  para  apreciar  rápidamente  dónde 
termina  el  flujo  de  actividad. 

•  Si  tenemos  actividades  que  no  tienen  entrada  pero  sí  salidas,  o  al 
revés,  debemos  considerar  nuestra  representación,  algo  estare¬ 
mos  haciendo  mal... 

•  El  rombo  que  indica  una  decisión  no  tiene  la  condición  escrita 
dentro  a  diferencia  de  los  diagramas  de  flujo.  Es  en  las  activida¬ 
des  que  salen  de  él  donde  escribiremos  la  condición  evaluada  y 
el  resultado  obtenido  para  seguir  por  esa  transición. 

•  Las  guardas  de  los  rombos  de  decisión  deben  contemplar  todos 
los  casos  posibles.  Es  correcto  añadir  una  transición  con  una  con¬ 
dición  [en  caso  contrario]. 

•  La  paralelización  ( fork )  y  la  sincronización  (/’o/n)  no  pueden  ocurrir 
simultáneamente.  Un  fork  sólo  puede  tener  una  entrada  y  un  join 
una  salida. 


2.9.  Diagrama  de  clases 


La  realización  de  un  diagrama  de  clases  está  en  la  frontera  entre  el 
análisis  y  el  diseño.  Probablemente  es  el  diagrama  UML  más  cono¬ 
cido  (con  permiso  de  los  casos  de  uso),  y  nos  permite  identificar  la 
estructura  de  clases  del  sistema  incluyendo  las  propiedades  y  méto¬ 
dos  de  cada  clase. 
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También  representaremos  las  relaciones  que  existen  entre  las  clases 
tales  como  herencia,  generalización,  etc.,  manteniendo  la  misma 
notación  vista  en  anteriores  diagramas  para  casos  similares. 


Gran  parte  de  la  popularidad  de  este  tipo  de  diagrama  es  que  nu¬ 
merosas  herramientas  de  desarrollo  soportan  la  generación  de  códi¬ 
go  a  partir  de  esta  representación  visual,  lo  que  facilita  mucho  el 
trabajo  y  evita  muchos  errores  en  las  fases  iniciales  del  proyecto. 
Además,  algunas  de  estas  herramientas  no  sólo  soportan  la  genera¬ 
ción  inicial  de  código,  sino  que  son  capaces  de  actualizar  el  diagra¬ 
ma  a  partir  del  código  fuente  (ingeniería  inversa)  o  actualizar  el 
código  a  medida  que  vamos  introduciendo  cambios  en  el  modelo 
aunque  éste  haya  sido  ya  modificado  por  los  desarrolladores  (siem¬ 
pre  bajo  un  entorno  y  unas  condiciones  especiales,  claro  está). 


Los  elementos  presentes  en  este  diagrama  son  únicamente  las  clases, 
y  sus  relaciones: 


•  Clase:  se  representa  mediante  un  rectángulo  dividido  en  tres 
secciones.  En  la  parte  superior  deberemos  indicar  su  nombre,  a 
continuación  sus  propiedades  o  atributos  y  en  la  tercera  sección 
sus  métodos.  Elementos  auxiliares  ya  vistos  como  los  estereoti¬ 
pos  (p.  e¡.  < <interfaz> >)  también  pueden  aparecer  ¡unto  al 
nombre  de  la  clase.  Los  atributos  y  los  métodos  pueden  incorpo¬ 
rar  información  adicional  como  por  ejemplo  el  tipo  de  acceso 
(público,  privado,  protegido),  el  tipo  de  datos  de  los  atributos  y 
los  parámetros  de  los  métodos,  etc. 


Figura  29 
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En  la  clase  representada,  todos  los  atributos  son  privados,  y  los 
métodos  públicos. 


Pueden  verse  indicados  también  los  tipos  de  datos  de  unos  y 
otros. 


•  Asociación:  representa  una  relación  genérica  entre  dos  clases,  y 
su  notación  es  simplemente  una  línea  que  las  une,  donde  pode¬ 
mos  indicar  la  multiplicidad  de  la  relación  en  cada  extremo  (uno 
a  uno,  uno  a  n,  n  a  m). 


•  Composición,  agregación:  tal  como  vimos  en  el  capítulo  de  in¬ 
troducción,  si  una  clase  está  compuesta  de  otras,  donde  estas 
otras  no  pueden  existir  sin  la  primera,  tendrán  una  relación  de 
composición  con  la  clase  padre.  Cuando  simplemente  una  clase 
incluye  a  otra,  pero  la  incluida  tiene  entidad  en  sí  misma,  habla¬ 
remos  de  agregación. 


•  Dependencia:  cuando  una  clase  depende  de  otra  en  el  sentido  de 
que  la  usa  como  atributo  o  parámetro  de  algún  método,  puede 
expresarse  mediante  una  relación  de  dependencia. 


•  Generalización:  es  el  equivalente  a  la  herencia  o  extensión  tal 
como  hemos  visto  en  otros  diagramas. 
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Veamos  un  ejemplo: 


Figura  30.  Diagrama  de  clases 


Puede  verse  que  las  relaciones  de  generalización  y  agregación  usan 
la  misma  notación  vista  en  otros  diagramas,  lo  que  contribuye  a  la 
coherencia  entre  los  modelos  y  facilita  su  comprensión  y  representa¬ 
ción.  En  algunos  casos,  hemos  creído  necesario  incluir  etiquetas  en 
las  relaciones,  ya  que  clarifican  el  diagrama.  En  otros  casos  (como 
veremos  en  el  capítulo  de  generación  de  código)  puede  ser  intere¬ 
sante  representar  también  el  rol  que  juega  cada  clase  en  la  relación. 


La  relación  de  implementación  de  la  interfaz,  la  hemos  expresado 
con  la  notación  de  dependencia. 
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El  diagrama  expresa  también  perfectamente  las  clases  que  se  tienen 
a  ellas  mismas  como  uno  de  sus  atributos,  como  es  el  caso  de  "De¬ 
partamento". 


El  modelado  de  clases  no  presenta  ninguna  dificultad  en  cuanto  a 
la  representación  en  sí  misma,  la  dificultad  está  en  identificar  las 
relaciones  existentes  entre  las  clases  que  componen  el  sistema.  Para 
ello  es  imprescindible  tener  muy  claros  los  conceptos  vistos  en  el  apar¬ 
tado  correspondiente  a  la  introducción  a  la  orientación  a  objetos  y 
consultar  la  numerosa  bibliografía  existente. 


A  más  alto  nivel,  es  posible  representar  los  diagramas  de  clases  sin 
información  relativa  a  su  implementación,  de  una  forma  similar  a  la 
siguiente: 


Figura  31 


Proyecto 


+  Nombre 
+  Descripc¡ón 
+  Fecha  estimada  de  inicio 
+  Fecha  estimada  de  fin 


+  Calcular  estimaciones!) 
+  Cerrar() 


-t-ldentificador 
-I-Título 
-t-Descripcián 
n  +Horas  invertidas 


+  Añadir  Nota() 

+  Borrar  NotaQ 
+  Consultar  Estado)) 
+  Cerrar  Tarea() 


Esta  representación  puede  ser  muy  útil  en  fases  iniciales,  y  si  se  hace, 
facilita  mucho  la  creación  del  diagrama  de  clases  detallado  cuando 
llegue  el  momento. 

A  continuación,  veamos  algunas  de  las  buenas  prácticas  a  tener  en 
cuenta  al  representar  diagramas  de  clases,  aunque  algunas  de  ellas 
hacen  referencia  también  al  diseño  de  las  propias  clases: 

•  La  visibilidad  de  los  atributos  (público:  +;  protegido:  #;  privado:  -) 
es  recomendable  usarla  sólo  en  fase  de  diseño.  Se  trata  de  un  as¬ 
pecto  importante  en  el  diseño  del  objeto  y  no  debería  obviarse,  pero 
en  diagramas  conceptuales  no  es  necesario,  ya  que  quizá  en  fases 
posteriores  habrá  métodos  que  se  conviertan  en  atributos  y  al  con¬ 
trario.  El  mismo  argumento  puede  usarse  para  los  tipos  de  datos. 

•  Los  nombres  de  los  métodos  y  los  atributos  deberían  reflejar  las 
convenciones  en  cuanto  a  denominación  del  lenguaje  de  progra¬ 
mación  en  que  vayamos  a  implementar  el  sistema.  Es  importante 
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no  sólo  por  coherencia,  sino  por  aprovechar  las  ventajas  que  nos 
ofrecerán  los  generadores  de  código. 


Cuando  una  asociación  tiene  métodos  o  atributos,  deberemos 
modelarla  como  una  clase  que  se  asocia  con  las  dos  anteriores. 


No  es  necesario  incluir  los  métodos  de  acceso  y  modificación  de 
los  atributos  (típicamente  getXXX  y  setXXX).  Pueden  darse  por  su¬ 
puestos  en  el  modelo  y  la  mayoría  de  generadores  de  código  los 
generan  de  forma  automática  o  bajo  demanda. 


Si  debemos  dejar  alguna  lista  de  parámetros  incompleta,  indicar¬ 
lo  mediante  una  elipsis  (...). 


Los  atributos  y  operaciones  estáticas  (representadas  con  el  nom¬ 
bre  subrayado  en  el  diagrama)  deberían  aparecer  antes  que  las 
de  instancia  (el  resto).  Siguiendo  el  mismo  criterio,  es  conveniente 
ordenar  los  métodos  y  atributos  según  su  visibilidad  descendiente: 
públicos  -»  protegidos  — >  privados. 


No  conviene  abusar  de  los  estereotipos.  Algunas  herramientas  in¬ 
cluyen  estereotipos  del  tipo  < <constructor> >  o  <<getter>>  en 
los  métodos  correspondientes.  Esto  sólo  contribuye  a  añadir  com¬ 
plejidad  al  diagrama  sin  proporcionar  información  valiosa. 


Si  nuestro  modelo  incluye  múltiples  interfaces,  puede  ser  útil  in¬ 
cluirlos  en  otro  diagrama  y  utilizar  la  notación  para  la  clase  que 
implemente  la  interfaz  del  diagrama  de  componentes  en  el 
diagrama  de  clases  (el  círculo  cerrado).  Evidentemente,  se  des¬ 
aconseja  repetir  los  atributos  y  métodos  de  la  interfaz  que  imple- 
menta  una  clase. 


Es  aconsejable  indicar  siempre  la  multiplicidad  de  una  relación.  Nos 
será  útil  para  entender  mejor  el  tipo  de  relación  y  ayudará  también 
al  generador  de  código.  Conviene  ser  escrupuloso  en  su  especifica¬ 
ción,  y  concretar  si  la  relación  es  0..1 ,  1 , 0..n,  1  ..n,  o  n..m. 


•  No  es  necesario  modelar  todas  las  dependencias.  Esto  da  como  re¬ 
sultado  diagramas  completamente  saturados  de  asociaciones  que 
no  aportan  información.  Es  más  conveniente  modelar  sólo  las 
que  aportarán  algo  al  modelo. 


•  Si  existen  varias  relaciones  entre  dos  clases,  puede  ser  interesan¬ 
te  indicar  el  rol  que  ocupan  ellas  en  cada  una.  El  rol  se  indica 
¡unto  a  la  multiplicidad  mediante  el  sujeto  de  la  oración  que 
contendría  el  verbo  de  la  asociación  (p.  e¡.  "nueva  propuesta", 
"antiguo  cliente",  etc.). 


2.10.  Diagrama  de  despliegue 


El  diagrama  UML  de  despliegue  representa  una  vista  estática  de  la 
configuración  en  tiempo  de  ejecución  de  los  nodos  que  intervienen 
en  el  proceso  y  de  los  componentes  que  se  ejecutan  en  esos  nodos. 
Puede  mostrar  el  hardware  del  sistema  y  los  paquetes  software  que 
hay  instalados  en  él,  el  mlddleware  que  los  conecta,  etc. 


También  son  útiles  para  explorar  la  arquitectura  de  sistemas  embe¬ 
bidos,  mostrando  los  componentes  hardware  y  software,  así  como 
sus  protocolos  o  formas  de  comunicarse. 
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En  el  diagrama  de  despliegue  anterior,  las  cajas  tridimensionales  re¬ 
presentan  los  nodos  del  sistema,  tanto  software  como  hardware.  Po¬ 
demos  clarificar  de  qué  se  trata  exactamente  cada  uno  mediante 
estereotipos,  siempre  que  éstos  ayuden  a  entender  el  diagrama. 


Las  conexiones  entre  nodos  del  sistema  pueden  etiquetarse  con  el 
protocolo  de  comunicación  en  que  se  implementan.  Los  nodos  pue¬ 
den  contener  subnodos,  o  componentes  software.  Los  componentes 
software  usan  la  misma  notación  que  en  los  diagramas  de  compo¬ 
nentes,  por  lo  que  podríamos  añadir  la  notación  acerca  de  sus  inter¬ 
faces  si  fuera  necesario,  aunque  al  nivel  al  que  se  representan  los 
diagramas  de  despliegue  no  suele  serlo. 

En  configuraciones  complejas,  los  diagramas  de  despliegue  pueden 
extenderse  rápidamente  si  indicamos  todos  los  ficheros  de  configu¬ 
ración,  especificaciones  de  arquitecturas  y  versiones  de  cada  compo¬ 
nente  implicado.  Esta  es  la  información  que  sería  realmente  útil  para 
los  desarrolladores  que  deben  implantar  o  mantener  el  sistema,  pero 
no  parece  que  UML  proporcione  las  herramientas  para  representarlo 
de  forma  compacta. 

Veamos  el  mismo  ejemplo  más  detallado  para  comprobarlo. 


Vemos  que  la  inclusión  de  ficheros  de  configuración,  versiones,  es¬ 
pecificaciones  de  despliegue,  etc.  empieza  a  complicar  el  diagrama 
cuando  quizá  una  simple  hoja  de  requisitos  y  unas  instrucciones  de 
despliegue  textuales  ¡unto  con  el  primer  diagrama  serían  más  útiles. 
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Así  pues,  cuando  trabajemos  con  diagramas  de  componentes  es  re¬ 
comendable  seguir  estas  prácticas: 

•  Indicar  sólo  los  componentes  software  clave  para  el  proyecto. 


•  Es  importante  denominar  los  nodos  con  nombres  descriptivos  que 
sean  útiles  para  los  desarrolladores. 


•  Intentar  no  abusar  de  los  estereotipos,  y  mantener  una  coherencia 
en  su  nomenclatura  con  el  resto  de  diagramas. 


•  Las  comunicaciones  también  pueden  incorporar  estereotipos,  in¬ 
dicando  por  ejemplo  si  la  comunicación  es  síncrona  o  asincrona, 
si  se  trata  de  un  servicio  web,  etc. 


No  es  necesario  modelar  todas  las  dependencias  de  los  componen¬ 
tes  dentro  de  un  nodo.  Se  entiende  que  por  ejemplo  los  ficheros  de 
configuración  o  especificaciones  de  entorno  de  ejecución  van  a  ser 
leídos  por  el  nodo  u  otro  componente  del  mismo.  El  desarrollador  lo 
sabrá  y  en  la  mayoría  de  los  casos  no  será  necesario  representar 
asociaciones  de  estos  componentes  con  el  resto. 


2.1 1 .  Diagrama  de  estados 


El  propósito  de  los  diagramas  de  estados  es  documentar  las  diferen¬ 
tes  modalidades  (los  estados)  por  las  que  una  clase  puede  pasar  y 
los  eventos  que  provocan  estos  cambios  de  estado.  A  diferencia  de 
los  diagramas  de  actividades  o  de  secuencia  que  muestran  las  tran¬ 
siciones  e  interacciones  entre  clases,  habitualmente  el  diagrama  de 
estados  muestra  las  transiciones  dentro  de  una  misma  clase. 


Normalmente  lo  usaremos  en  combinación  con  los  casos  de  uso, 
para  tener  acotados  los  casos  que  provocarán  cambios  de  estado  en 
un  objeto.  No  todas  las  clases  van  a  necesitar  un  diagrama  de  este 
tipo,  y  normalmente  van  a  usarse  como  complemento  de  los  diagra¬ 
mas  de  actividades  y  de  los  de  colaboración. 
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En  cuanto  a  la  notación,  comparten  muchos  elementos  con  otros 
diagramas  que  representan  el  comportamiento  del  modelo,  como 
los  diagramas  de  actividad  y  colaboración  ya  mencionados. 


•  Estado:  representa  el  estado  de  un  objeto  en  un  instante  de  tiem¬ 
po.  Tendremos  tantos  símbolos  de  estado  en  el  diagrama  como 
estados  diferentes  para  cada  objeto  haya  que  modelar.  Su  apa¬ 
riencia  es  similar  a  la  representación  de  una  clase,  pero  con  las 
esquinas  redondeadas. 


•  Estados  inicial  y  final:  son  pseudoestados  que  mostrarán  el  punto 
de  inicio  y  final  del  flujo  de  actividad.  Su  condición  de  pseudoes- 
tado  viene  dada  por  el  hecho  de  que  no  tiene  variables  ni  accio¬ 
nes  definidas. 


•  Transiciones:  una  flecha  indicará  la  transición  entre  estados.  En 
ella  describiremos  el  evento  que  ha  disparado  la  transición,  y  la 
acción  que  provoca  el  cambio.  Existen  transiciones  en  las  que  no 
existe  un  evento  que  las  provoque  (por  ejemplo,  ha  finalizado  una 
actividad  que  estaba  realizando). 


íifkpeitJnNoFosible]/ 

*noPlanificado{) 


asignarProgramador 
_  (empleodoID) 


asigna  rProgramodor 
(empleadolDl^. 


planificar 


■echalnicio,  fechaFin) 


Figura  34.  Diagrama  de  estados  de  la  clase  Proyecto 


asi<jharProgramador(empleadolD)[planificodo] 

eliminarProgramador() 
[ultimo] 


El  ejemplo  muestra  las  transiciones  que  ocurren  en  el  objeto  "Proyecto" 
durante  su  creación.  En  este  caso,  la  transición  puede  mostrar  única¬ 
mente  la  acción  que  se  realiza,  el  evento  que  ocurre  o  la  condición 
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para  que  se  realice  la  acción  en  concreto.  En  su  notación  más  comple¬ 
ta,  se  representa  de  la  forma  siguiente: 

evento ( )  [condición]  acción  () 

Vemos  que  una  acción  puede  ir  iterando  sobre  el  mismo  estado  según 
una  condición.  En  el  ejemplo  podemos  ir  asignando  programadores 
al  proyecto,  mientras  el  estado  del  objeto  sigue  reflejando  que  tiene  pro¬ 
gramadores  asignados,  en  el  momento  en  que  eliminamos  el  último 
programador,  éste  pasa  al  estado  "Sin  programadores  asignados" 
del  que  puede  salir  mediante  la  acción  asignarProgramador  () . 

Al  examinar  el  diagrama,  nos  damos  cuenta  rápidamente  de  lo  que  co¬ 
mentábamos  al  inicio:  el  diagrama  de  estados  es  una  representación 
con  mucho  detalle,  y  sólo  será  necesaria  en  casos  donde  los  diagramas 
de  casos  en  los  que  interviene  un  objeto  o  los  diagramas  de  secuencia 
en  los  que  interviene  no  proporcionen  toda  la  información  necesaria. 

Al  igual  que  en  otros  diagramas,  puede  ser  interesante  encapsular 
los  estados  en  zonas  que  clarifiquen  la  acción  global  que  estamos 
realizando  o  en  subestados  de  la  misma.  Veamos  otro  ejemplo: 


comunicar() 


comunicar() 


Figura  35.  Diagrama  de  estados  con  un  subestado 


ubestados 
e  la 

ctualización 
e  la  tarea 


actuolizar() 


comunicad) 
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En  este  caso  se  aprecian  algunas  incoherencias  en  la  representación, 
producto  de  la  herramienta  que  hemos  utilizado.  Teóricamente,  la 
transición  hacia  el  subestado  debería  hacerse  hacia  el  estado  inicial 
de  la  misma,  pero  la  herramienta  impide  realizar  una  transición  ha¬ 
cia  un  estado  inicial.  Lo  mismo  ocurre  con  el  estado  final  del  subestado, 
debería  haber  la  transición  hacia  el  estado  "Comunicada",  pero  la 
herramienta  impide  que  haya  transiciones  desde  un  estado  final. 


Veamos  las  buenas  prácticas  relacionadas  con  los  diagramas  de  es¬ 
tados: 


•  Ordenar  de  arriba  abajo  los  estados  y  sus  transiciones  (en  concreto 
el  estado  inicial  y  final)  ayuda  a  la  comprensión  del  diagrama. 


•  Para  incrementar  el  valor  de  comunicación  del  diagrama,  es  im¬ 
portante  prestar  atención  a  los  nombres  de  los  estados.  Se  acon¬ 
seja  usar  verbos  en  presente  (Actualizar,  Presentar)  o  bien  en 
participio  (Actualizado,  Presentado). 


•  Al  igual  que  en  los  diagramas  de  actividad,  habrá  que  vigilar  con 
los  estados  que  sólo  emiten  transiciones  pero  no  provienen  de 
ninguna,  y  de  los  estados  que  sólo  reciben  transiciones  pero  no 
expresan  un  cambio  de  estado  del  objeto. 


•  Si  es  posible,  suele  ser  conveniente  nombrar  las  acciones  con  los 
métodos  que  van  a  hacer  cambiar  el  estado  del  objeto.  De  esta 
forma  se  incrementa  la  coherencia  del  diagrama  con  el  resto. 


•  Si  en  un  estado  todas  sus  transiciones  de  salida  o  de  entrada  co¬ 
rresponden  a  la  misma  acción,  y  sólo  varían  en  su  condición,  es 
correcto  situar  el  nombre  de  la  acción  dentro  del  estado  y  sólo  in¬ 
dicar  la  condición  en  cada  transición. 


•  De  forma  similar  a  los  diagramas  de  actividad,  deberemos  repa¬ 
sar  las  condiciones  de  las  transiciones  para  asegurarnos  de  que 
no  hay  un  caso  en  que  pueda  haber  dos  transiciones  posibles. 
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2.12.  Diagrama  de  colaboración 

Al  igual  que  otros  diagramas  UML  basados  en  el  comportamiento 
del  sistema,  los  diagramas  de  colaboración  modelan  las  interaccio¬ 
nes  entre  objetos.  Muchos  autores  lo  consideran  una  variación  de  los 
diagramas  de  secuencia  donde  los  objetos  no  están  en  filas  y  columnas, 
sino  distribuidos  libremente  y  con  los  mensajes  numerados  para  se¬ 
guir  las  posibles  secuencias  de  mensajes. 

Los  elementos  que  intervienen  son  Objetos,  Actores  y  Mensajes,  en 
la  misma  notación  que  en  anteriores  diagramas. 


Figura  36.  Diagrama  de  colaboración  representando 
los  mensajes  entre  objetos  al  cerrar  un  proyecto 


Vemos  rápidamente  que  el  nivel  de  información  es  prácticamente  idén¬ 
tico  al  de  un  diagrama  de  secuencia,  con  las  siguientes  excepciones: 

•  No  se  contemplan  los  retornos  ni  los  errores.  Simplemente  los 
mensajes  que  se  intercambian  los  objetos  entre  sí. 

•  La  secuencia  es  más  difícil  de  seguir,  hay  que  mirar  la  etiqueta  de 
los  mensajes. 


Por  claridad,  la  notación  de  un  diagrama  de  colaboración  es  más 
simple  que  en  un  diagrama  de  secuencia,  y  puede  ser  conveniente 
utilizarlo  cuando  el  orden  de  los  mensajes  no  es  importante.  Aprove¬ 
chando  su  similitud,  podemos  también  ampliar  su  notación  con  ele¬ 
mentos  de  los  diagramas  de  secuencia  (las  condiciones  entre  [  ],  la 
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llamada  a  casos  de  uso,  etc.)  y  obtener  un  diagrama  más  completo 
y  seguramente  más  entendible  por  personal  no  técnico  que  un 
diagrama  de  secuencia. 


Un  aspecto  importante  de  los  diagramas  de  colaboración  es  que 
muestran  los  roles  que  toma  cada  clase  en  la  comunicación.  En  el 
diagrama  puede  apreciarse  dos  instancias  de  la  clase  "Empleado" 
que  ocupan  los  roles  "JefeProyecto"  y  "Programador". 


Una  variación  de  este  diagrama  toma  el  nombre  a  veces  de  diagrama 
de  comunicación,  en  el  que  especificamos  los  objetos  que  se  comuni¬ 
can  entre  sí,  el  rol  que  ocupa  cada  uno  en  la  comunicación  y  la  multi¬ 
plicidad  de  unas  respecto  de  las  otras. 


Podría  decirse  que  este  diagrama  es  una  versión  preliminar  del 
diagrama  de  clases,  donde  reflejamos  también  la  comunicación  en¬ 
tre  las  mismas.  La  notación  de  los  mensajes  es  particular  para  este 
tipo  de  diagramas  y  tiene  la  forma  siguiente: 


[numeroSecuencia : ]  nombreMetodo (parametros )  [ : valorRetorno] 


o  a  veces  la  siguiente: 


[numeroSecuencia : ]  [valorRetorno : =] nombreMetodo (parametros ) 


Veamos  algunas  buenas  prácticas  relacionadas  con  ellos: 


•  Los  diagramas  de  colaboración  a  nivel  de  instancia  (como  el  del 
ejemplo)  son  útiles  para  explorar  posibles  problemas  en  el  diseño 
de  las  clases. 


•  Existe  una  variante  a  más  alto  nivel  de  este  diagrama  (a  nivel  de 
especificación),  que  suele  usarse  para  explorar  los  roles  que  ocu¬ 
parán  las  clases  en  el  sistema.  Esta  notación  no  es  muy  habitual, 
ya  que  es  casi  una  copia  de  la  notación  del  diagrama  de  clases 
pero  sin  representar  sus  métodos  y  atributos. 
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Figura  37.  Diagrama  de  colaboración  a  nivel  de  especificación 


•  Cabe  recordar  que  los  diagramas  de  colaboración  no  modelan 
el  flujo  de  proceso,  únicamente  las  interacciones  entre  objetos, 
y  esa  interacción  se  produce  a  través  de  los  mensajes  que  inter¬ 
cambian.  Si  deseamos  modelar  el  proceso  o  los  datos  que  intercam¬ 
bian,  debemos  utilizar  un  diagrama  de  actividades. 

•  Cuando  sea  clave  la  secuencia  en  que  se  producen  los  mensajes 
para  comprender  su  interacción,  es  mucho  más  conveniente  utili¬ 
zar  un  diagrama  de  secuencia. 

•  Cuando  representemos  los  mensajes,  es  importante  pintar  una  fle¬ 
cha  para  cada  mensaje,  y  sólo  incluir  los  datos  necesarios  para  com¬ 
prender  la  comunicación.  Si  los  parámetros  o  los  valores  de  retorno 
no  aportan  nada  a  la  comprensión  del  mismo,  no  son  necesarios. 


2.13.  Generación  de  código 


Hasta  el  momento,  hemos  hablado  de  la  representación  del  modelo 
que  nos  proporciona  UML,  de  su  notación  y  de  las  herramientas  que 
nos  ayudan  a  obtener  diagramas  y  documentación  para  nuestros 
proyectos  basándonos  en  este  estándar. 

En  los  primeros  pasos  de  UML,  fue  una  empresa  (Rational  Corp.)  la  que 
patrocinó  el  proyecto,  y  posteriormente  fueron  muchas  otras  las 
que  participaron  y  participan  en  el  comité  que  revisa  las  aportaciones 
e  ideas.  De  la  misma  manera  que  los  teóricos  en  modelado  y  represen¬ 
tación  aportaron  sus  ideas  para  la  notación,  las  empresas  se  preocu¬ 
paron  de  que  ésta  fuera  lo  suficientemente  completa  como  para  que 
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sus  herramientas  de  modelado  y  desarrollo  pudieran  generar  código  a 
partir  de  los  modelos. 

La  mayoría  de  las  empresas  que  participan  en  la  revisión  del  están¬ 
dar  comercializaban  entornos  de  desarrollo  que  ya  disponían  de  he¬ 
rramientas  de  generación  de  código  y  vieron  el  potencial  de  UML  y 
las  posibles  mejoras  en  sus  herramientas.  Lamentablemente,  ningu¬ 
na  de  estas  herramientas  es  de  código  abierto,  y  por  lo  tanto  no  las 
vamos  a  ver  aquí,  pero  al  ser  UML  un  estándar  abierto,  muchas  otras 
herramientas  de  modelado  de  código  abierto  (también  excelentes) 
han  ido  incorporando  esta  prestación  a  lo  largo  de  los  años. 

Las  tres  herramientas  que  hemos  utilizado  a  lo  largo  del  capítulo 
para  representar  los  diagramas  tienen,  en  mayor  o  menor  medida, 
soporte  para  la  generación  de  código  a  partir  de  los  modelos. 


2.13.1.  Dia  con  Pies 2 C ode 

El  software  de  modelado  Dia  disponible  en  http://www.gnome.org/ 
projeets/dia/  no  incorpora  directamente  una  herramienta  de  gene¬ 
ración  de  código,  pero  existen  varias  herramientas  que  trabajan  con¬ 
juntamente  con  él,  ya  sea  para  generar  diagramas  en  su  formato, 
como  para  extraer  información  de  sus  diagramas  y  trabajar  con  ella. 
Este  es  el  caso  de  Dia2Code. 

Dia2Code  está  disponible  en  http://dia2code.sourceforge.net/  y  la 
última  versión  estable  es  la  0.81.  Es  un  programa  ejecutable  desde 
línea  de  comandos  que  toma  los  siguientes  parámetros: 


Usage:  dia2code  [-h|--help]  [-d  <dir>]  [-nc]  [-el  <classlist>] 

[-t  (ada | c | cpp | idl | java | php | python | shp | sql) ]  [-v] 

[-1  clicense  file>]  <diagramf ile> 


-h  --help 
-t  <target> 


-d  <dir> 

-1  <license> 

-nc 

-el  <classlist> 


Print  this  help  and  exit 

Selects  the  output  language.  <target>  can  be 
one  of:  ada, c, cpp, idl, java, php, python, shp  or  sql. 
Default  is  C++ 

Output  generated  files  to  <dir>,  default  is 
License  file  to  prepend  to  generated  files. 

Do  not  overwrite  files  that  already  exist 
Generate  code  only  for  the  classes  specified  in 
the  comma-separated  <classlist>. 

E.g:  Base, Derived . 
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Invert  the  class  list  selection.  When  used 


without  -el  prevents  any  file  from  being  created 
<diagramf ile>  The  Dia  file  that  holds  the  diagram  to  be  read 

Note:  parameters  can  be  specified  in  any  order. 


A  primera  vista,  vemos  que  el  número  de  lenguajes  de  programación 
soportados  es  notable.  Particularmente  interesante  es  el  soporte  de 
Python  y  PHP,  no  muy  habituales  en  estas  herramientas,  ni  tan  siquie¬ 
ra  en  las  comerciales. 

Cabe  decir  que  para  que  Dia2Code  interprete  correctamente  el 
diagrama  UML,  éste  debe  realizarse  con  las  herramientas  específicas 
UML  que  proporciona  Dia,  no  pintando  los  mismos  símbolos.  Esto 
parece  evidente  pero  es  importante  por  que  Dia  es  una  herramienta 
de  diagramas  genérica  y  sería  posible  obtener  el  mismo  resultado  re¬ 
presentando  los  elementos  con  otras  formas  de  su  biblioteca: 


Figura  38.  Captura  de  pantalla  de  Dia  mostrando 
las  propiedades  de  una  clase 
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El  diagrama  sobre  el  que  vamos  a  generar  código  es  el  que  presen¬ 
tamos  en  el  capítulo  correspondiente  al  diagrama  de  clases.  Para 
que  la  generación  de  código  sea  realmente  útil,  es  conveniente  pro¬ 
porcionar  toda  la  información  sobre  las  clases,  métodos,  atributos  y 
cada  una  de  las  asociaciones.  Así  pues,  conceptos  como  el  rol  que 
juega  cada  extremo  de  las  asociaciones  son  importantes,  ya  que  es 
presumible  que  el  programa  generador  las  utilice  para  generar  el 
atributo  correspondiente  a  la  asociación.  Veamos  cómo  queda  re¬ 
presentado  el  diagrama  completo  en  Dia: 


Figura  39.  Diagrama  de  clases  representado  en  Dia 


Zaoni  100.0".  I  v>  ¡  , 


Y  ahora  lanzamos  el  programa  generador  de  código  sobre  el  fichero 
del  diagrama.  Para  este  ejemplo  vamos  a  generar  código  Java: 


[marcg@lynx  src] $  dia2code  -t  java  -d  /tmp/uocFiles/  Diagrama26 .dia 

Comprobamos  que  se  han  generado  los  ficheros  para  las  clases.  A 
continuación  veamos  los  casos  más  interesantes  y  cuál  ha  sido  el  có¬ 
digo  obtenido: 


public  class  Propuesta  { 

/**  Attributes  */ 
private  int  propuestaID; 
private  string  titulo; 
private  int  fecha; 
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/**  Associations  */ 
private  Comercial  propuesta; 

/  *  * 

*  Operation 

* 

*/ 

public  void  aceptar  (  ) { 

} 

/  *  * 

*  Operation 

* 

*  @param  concepto 
*/ 

public  void  anadirConcepto  (  ConceptoPropuesta  concepto  ) { 


import  Empleado; 

public  class  Comercial  extends  Empleado  { 
/**  Attributes  */ 
private  float  comisionPactada; 
private  int  objetivosAnuales; 

I  -k  -k 

*  Operation 

k 

*  @param  ano 

*  @return  Vector 
*/ 

public  Vector  listarVentas  (  int  ano  ) { 

} 


import  Comunicar; 

public  class  Cliente  implements  Comunicar  { 
/**  Attributes  */ 
private  int  clienteID; 
private  string  nombre; 
private  string  razonSocial; 
private  string  nif; 
private  dirección; 

I  -k  -k 

*  Operation 

k 

*  Sreturn  Vector 
*/ 

public  Vector  listarFacturas  (  ) { 

} 


import  Propuesta; 
import  Cliente; 
import  AccionComercial ; 


public  class  ContactoComercial  { 
/**  Attributes  */ 
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private  int  contactoID; 
private  string  nombre; 
private  string  apellidos; 
private  string  dirección; 
private  string  comentario; 
private  string  estado; 

/**  Associations  */ 
private  Propuesta  propuesta; 
private  Cliente  cliente; 
private  AccionComercial  acción; 

/  *  * 

*  Operation 

~k 

*  / 

public  void  borrar  (  ) { 

} 

/  *  * 

*  Operation 

~k 

*  @param  nuevoEstado 
*/ 

public  void  cambiarEstado  (  string  nuevoEstado  ) { 
} 


Podemos  ver  cómo  se  han  generado  correctamente  las  importacio¬ 
nes  entre  clases,  los  atributos  y  los  métodos.  Destacable  es  también 
la  inclusión  de  comentarios  al  estilo  JavaDoc. 


Por  lo  que  respecta  a  las  particularidades  del  modelo,  el  generador 
ha  entendido  perfectamente  las  relaciones  de  herencia  ("extends"), 
la  generalización  y  la  implementación  de  la  interfaz  por  parte  de  la 
clase  "Cliente".  En  todos  los  casos  ha  incluido  la  declaración  de  atri¬ 
butos  con  los  nombres  de  roles  que  hemos  representado  en  el 
diagrama.  Por  lo  que  respecta  a  la  multiplicidad  en  las  asociaciones, 
es  lógico  que  la  generación  no  incluya  atributos  para  las  asociacio¬ 
nes  con  multiplicidad  mayor  que  uno,  ya  que  éstas  se  implementaran 
mediante  métodos  (p.  e¡.  anadirContacto  ( ) ,  borrarContacto  ( ) ) 
y  no  con  vectores  u  otras  estructuras  de  datos  estáticas  (aunque  otros  ge¬ 
neradores  toman  enfoques  diferentes,  como  veremos). 


Dia  ha  modelado  todos  los  métodos  de  cada  clase,  pero  no  ha 
incluido  métodos  getXXX  y  setXXX  para  cada  atributo.  Si  queremos 
que  el  generador  los  incluya  en  el  código  fuente,  deberemos  re¬ 
presentarlos  en  el  modelo,  a  pesar  de  añadir  información  irrele¬ 
vante  al  diagrama. 


120 


2.1 3.2.  Umbrello 


El  software  de  modelo  Umbrello  disponible  en  http://uml.sourceforge.net 
o  como  parte  del  paquete  "kdesdk"  del  entorno  KDE,  ha  evolucionado 
rápidamente  durante  los  últimos  años  y  actualmente  mantiene  un  alto 
grado  de  actividad  en  su  proyecto. 


A  diferencia  de  Dia,  Umbrello  es  una  aplicación  totalmente  orienta¬ 
da  al  modelado  UML  y  por  ello  dispone  de  herramientas  que  facilitan 
mucho  la  creación  de  todos  los  tipos  de  diagramas.  Entre  ellas,  des¬ 
taca  la  barra  lateral  izquierda  donde  aparecen  todos  los  elementos 
UML  que  hemos  creado  en  algún  diagrama  para  poder  aprovechar¬ 
los  en  los  nuevos  diagramas  que  realicemos  del  mismo  modelo. 


La  generación  de  código  es  muy  completa,  y  disponemos  de  un  asis¬ 
tente  que  nos  presenta  multitud  de  opciones.  A  continuación  pode¬ 
mos  ver  las  disponibles  para  la  generación  de  código  Java: 


Figura  40.  Cuadro  de  diálogo  con  las  opciones 
de  generación  de  código  Java  en  Umbrello 
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Éste  es  el  aspecto  del  diagrama  de  clases  representado  en  Umbrello: 


Figura  41 .  Diagrama  de  clases  representado  en  Umbrello 
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El  código  fuente  de  las  clases  generadas  es  muy  completo.  Los  co¬ 
mentarios  están  en  formato  JavaDoc,  y  aunque  no  aprovechemos  las 
opciones  de  documentación  de  las  clases  y  métodos  que  ofrece  el 
propio  Umbrello,  él  ya  genera  mucha  información. 


import  Empleado; 
import  Propuesta; 

!  -k-k 

*  Class  Comercial 


*/ 

public  class  Comercial  extends  Empleado  { 

//  Fields 
// 

private  float  comisionPactada; 

// 

private  int  ob j etivosAnuales ; 

// 

public  List  propuestaVector  =  new  Vector (  ) ; 

//  Methods 

//  Constructors 

//  Empty  Constructor 

public  Comercial  (  )  {  } 

//  Accessor  Methods 
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/  *  * 

*  Get  the  valué  of  comisionPactada 

* 

*  @return  the  valué  of  comisionPactada 
*/ 

private  float  getComisionPactada  (  )  { 

return  comisionPactada; 

} 

/  *  * 

*  Set  the  valué  of  comisionPactada 

* 

* 

*/ 

private  void  setComisionPactada  (  float  valué  )  { 

comisionPactada  =  valué; 

} 

/  *  * 

*  Get  the  valué  of  objetivosAnuales 

* 

*  @return  the  valué  of  objetivosAnuales 
*/ 

private  int  getOb j etivosAnuales  (  )  { 

return  objetivosAnuales; 

} 

/  *  * 

*  Set  the  valué  of  objetivosAnuales 

* 

* 

*/ 

private  void  setObj etivosAnuales  (  int  valué  )  { 

objetivosAnuales  =  valué; 

} 

/  *  * 

*  Add  an  object  of  type  Propuesta  to  the  List  propuestaVector 

* 

*  @return  void 
*/ 

public  void  addPropuesta  (  Propuesta  valué  )  { 

propuestaVector . add (valué) ; 


/  *  * 

*  Remove  an  object  of  type  Propuesta  from  the  List  propuestaVector 

* 

*/ 

public  void  removePropuesta  (  Propuesta  valué  )  { 

propuestaVector . remove (valué) ; 


/  *  * 

*  Get  the  list  of  propuestaVector 

* 

*  Oreturn  List  of  propuestaVector 
*/ 

public  List  getPropuestaList  (  )  { 

return  (List)  propuestaVector; 

} 

//  Operations 
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/  *  * 

•k 

*  @param  ano 

*  @return  Vector 
*/ 

public  Vector  listarVentas  (  int  ano)  { 


import  ContactoComercial; 
import  Comunicar; 

/  *  * 

*  Class  Cliente 

* 


*/ 


public  class  Cliente  implements  Comunicar  { 
//  Fields 
// 

private  int  clienteID; 

// 

private  String  nombre; 

// 

private  String  razonSocial; 

// 

private  String  nif; 

// 

private  String  dirección; 

// 


public  ContactoComercial  contacto  =  new  ContactoComercial  (  ) 

//  Methods 

/ /  Constructors 

//  Empty  Constructor 

public  Cliente  (  )  {  } 

//  ñccessor  Methods 


/  *  * 


*  Get  the  valué  of  clienteID 


■ k 


*  @return  the  valué  of  clienteID 
*/ 

private  int  getClienteID  (  )  { 

return  clienteID; 


/  *  * 

*  Set  the  valué  of  clienteID 

k 

k 

*/ 

private  void  setClienteID  (  int  valué  )  { 

clienteID  =  valué; 

} 

/  k  k 

*  Get  the  valué  of  nombre 

k 
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*  @return  the  valué  of  nombre 
*/ 


private  String  getNombre  (  )  { 

return  nombre; 

} 

/  *  * 

*  Set  the  valué  of  nombre 

~k 

*/ 

private  void  setNombre  (  String  valué  )  { 

nombre  =  valué; 

} 

/  *  * 

*  Get  the  valué  of  razonSocial 

* 

*  @return  the  valué  of  razonSocial 
*/ 

private  String  getRazonSocial  (  )  { 

return  razonSocial; 

} 

/  *  * 

*  Set  the  valué  of  razonSocial 

* 

* 

*/ 

private  void  setRazonSocial  (  String  valué  )  { 

razonSocial  =  valué; 

} 

/  *  * 

*  Get  the  valué  of  nif 

* 

*  @return  the  valué  of  nif 
*/ 

private  String  getNif  (  )  { 

return  nif; 

} 

/  *  * 

*  Set  the  valué  of  nif 

* 

* 

*/ 

private  void  setNif  (  String  valué  )  { 

nif  =  valué; 

} 

/  *  * 

*  Get  the  valué  of  dirección 

* 

*  @return  the  valué  of  dirección 
*/ 

private  String  getDireccion  (  )  { 

return  dirección; 

} 

/  *  * 

*  Set  the  valué  of  dirección 

* 

* 

*/ 
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private  void  setDireccion  (  String  valué  )  { 

dirección  =  valué; 

} 

/  *  * 

*  Get  the  valué  of  contacto 

* 

*  @return  the  valué  of  contacto 
*/ 

public  ContactoComercial  getContacto  (  )  { 

return  contacto; 

} 

/  *  * 

*  Set  the  valué  of  contacto 

* 

* 

*/ 

public  void  setContacto  (  ContactoComercial  valué  )  { 

contacto  =  valué; 

} 

//  Operations 
/  *  * 


*  @return  Vector 
*/ 

public  Vector  listarFacturas  (  )  { 


Hemos  marcado  las  opciones  para  generar  los  métodos  de  acceso  a 
los  atributos,  y  así  lo  ha  hecho,  proporcionando  además  comentarios 
que  aunque  triviales,  sientan  la  base  para  que  los  completemos. 


Soporta  adecuadamente  todas  las  asociaciones,  herencia  e  imple- 
mentación  de  interfaces.  Además,  ha  generado  vectores  o  variables 
simples  en  las  asociaciones  según  la  multiplicidad  de  las  mismas,  y 
métodos  para  añadir,  borrar  y  obtener  la  lista  de  la  clase  asociada. 


Además  Umbrello  incorpora  la  posibilidad  de  importar  las  clases  a 
partir  de  sus  ficheros  fuente.  Esta  opción  nos  permite  disponer  del 
modelo  de  las  clases  ¡unto  con  sus  atributos  y  métodos,  pero  no  pinta 
el  diagrama  de  clases  correspondiente.  Para  ello,  simplemente  de¬ 
beremos  arrastrar  las  clases  desde  la  lista  situada  en  la  parte  izquier¬ 
da  hasta  el  diagrama  y  crear  las  asociaciones  que  Umbrello  no  haya 
detectado. 
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En  resumen,  podemos  decir  que  estamos  ante  una  muy  buena  herra¬ 
mienta,  que  cumple  con  los  objetivos  de  cualquier  proyecto  de  desa¬ 
rrollo  que  busque  un  software  de  modelado  con  generación  de 
código  de  calidad.  Además,  su  facilidad  de  uso  y  la  gran  cantidad 
de  lenguajes  de  programación  soportados  (cabe  destacar  el  soporte 
diferenciado  de  PHP4  y  PHP5,  Perl  y  XMLSchema)  nos  permite  dispo¬ 
ner  de  buenos  resultados  en  muy  poco  tiempo. 

2.13.3.  AraoUML 

El  entorno  de  modelado  ArgoUML  disponible  en  http://argouml.tigris.org 
es  quizá  el  más  completo  en  términos  de  cumplimiento  con  el  están¬ 
dar.  Es  un  proyecto  que  empezó  en  privado  en  1995  como  una  he¬ 
rramienta  CASE  y  en  1999  fue  evolucionando  hacia  un  proyecto  de 
código  abierto  integrando  el  modelado  UML  y  prestaciones  para  el 
desarrollo  rápido  de  aplicaciones. 


Esta  orientación  hacia  el  desarrollo  es  notoria  no  sólo  en  su  interfaz, 
donde  el  diagrama  juega  un  papel  casi  secundario,  también  en  el 
soporte  estricto  de  la  notación  y  en  prestaciones  como  las  críticas  au¬ 
tomáticas  al  diseño  o  consejos  que  vamos  recibiendo  a  medida  que 
nuestro  modelo  va  evolucionando. 


La  generación  de  código  no  ofrece  tantas  opciones  como  en  los  pro¬ 
gramas  anteriores  (sólo  genera  código  Java  y  la  propia  notación 
UML  1 .3),  no  soporta  la  inclusión  de  ficheros  de  licencia  o  cabeceras, 
etc.  El  enfoque  de  ArgoUML  es  totalmente  hacia  UML  como  notación 
y  el  diseño  de  aplicaciones  orientadas  a  objeto. 


Cabe  destacar  especialmente  la  prestación  de  "Críticas  al  diseño", 
donde  para  cada  clase,  atributo,  método  y  en  general  cualquier  ele¬ 
mento  del  modelo,  ArgoUML  nos  presenta  una  checklist  que  pode¬ 
mos  repasar  y  validar  para  mejorar  nuestro  diseño.  También  nos 
ofrece  críticas  en  general  sobre  el  diagrama  en  aspectos  como  la  no¬ 
tación  (el  uso  de  mayúsculas  y  minúsculas  en  los  nombres  de  clases, 
atributos  y  métodos),  el  uso  de  patrones  de  diseño,  la  inclusión  de 
constructores,  etc. 
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Éste  es  el 


aspecto  de  ArgoUML  mostrando  nuestro  diagrama  de  clases: 


Figura  42.  Diagrama  de  clases  representado  en  ArgoUML 


Podemos  ver  que  en  la  parte  izquierda  del  entorno  disponemos  del 
árbol  de  elementos  UML  que  incluye  nuestro  proyecto.  En  la  parte  in¬ 
ferior  es  donde  se  muestran  las  propiedades  del  elemento  seleccio¬ 
nado  (en  este  caso  una  clase),  y  en  la  parte  inferior  izquierda 
tenemos  los  consejos  de  diseño. 

Veamos  este  último  aspecto  con  un  poco  más  de  detalle: 


Vemos  que  la  información  que  ofrece  para  un  elemento  en  concreto 
(crear  el  constructor  de  una  clase)  es  muy  extensa  e  incluye  consejos 
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tanto  para  crear  el  constructor  con  el  programa,  como  sobre  la  im¬ 
portancia  del  mismo  y  de  las  implicaciones  que  tiene  en  UML. 

Como  hemos  comentado,  la  generación  de  código  no  ofrece  muchas 
opciones,  y  se  limita  a  crear  simplemente  los  métodos  representados, 
así  pues,  a  diferencia  de  los  programas  evaluados  anteriormente,  no 
generará  código  ni  para  el  constructor  ni  para  los  métodos  de  acceso 
a  los  atributos  ni  para  acceder  a  las  variables  representadas  para  las 
asociaciones. 


import  java. útil. Vector; 

public  class  Comercial  extends  Empleado  { 
/*  { src_lang=Java} */ 

private  float  comisionPactada; 

/*  {transient=false,  volatile=false} */ 

private  int  ob j etivosAnuales ; 

/*  {transient=false,  volatile=false} */ 


/  *  * 


*  @element-type  Propuesta 
*/ 

public  Vector  propuesta; 

public  void  listarVentas (int  ano)  { 

} 


import  java . lang. String; 
import  java. útil. Vector; 

public  class  Cliente  implements  Comunicar  { 
/*  { src_lang=Java} */ 


private  int  clienteID; 

/*  {transient=false,  volatile=false) */ 

private  String  nombre; 

/*  {transient=false,  volatile=false) */ 

private  String  razonSocial; 

/*  {transient=false,  volatile=false) */ 

private  String  nif; 

/*  {transient=false,  volatile=false} */ 

private  String  dirección; 

/*  {transient=false,  volatile=false} */ 

public  ContactoComercial  myContactoComercial; 
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public  ContactoComercial  contacto; 

public  Vector  listarFacturas ( )  { 

return  nuil; 

} 


import  j ava . lang . String; 
import  java .útil .Vector ; 

public  class  ContactoComercial  { 
/*  { src_lang=Java} */ 


private  int  contactoID; 

/*  {transient=false,  volatile=false} */ 

private  String  nombre; 

/*  {transient=false,  volatile=false} */ 

private  String  apellidos; 

/*  {transient=false,  volatile=false} */ 

private  String  dirección; 

/*  {transient=false,  volatile=false} */ 

private  String  comentario; 

/*  {transient=false,  volatile=false} */ 

private  String  estado; 

/*  {transient=false,  volatile=false} */ 

public  Cliente  cliente; 

/  *  * 

* 

*  @element-type  AccionComercial 
*/ 

public  Vector  acción; 

public  void  borrar ()  { 

} 

public  void  cambiarEstado (String  nuevoEstado)  { 

} 


Vemos  que  ha  generado  código  para  las  asociaciones  y  ha  respeta¬ 
do  correctamente  la  multiplicidad,  creando  un  Vector  para  la  multi¬ 
plicidad  múltiple,  y  una  instancia  para  el  resto. 


Debido  a  la  calidad  y  a  la  popularidad  de  este  software  en  su  área  de 
especialización  (el  modelado  de  diseño),  han  surgido  versiones  co¬ 
merciales  mejoradas  por  otros  fabricantes  de  software,  entre  las  que 
cabe  destacar  PoseidonUML  (http://www.gentleware.com/products/) 
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que  implemento  una  mucho  mejor  generación  de  código  e  integración 
con  entornos  de  desarrollo  como  Eclipse. 

ArgoUML  también  incorpora  funcionalidad  para  la  importación  de 
ficheros  fuente  (sólo  en  Java)  al  modelo,  de  modo  que  podamos 
aprovechar  esas  clases  en  los  diferentes  diagramas  que  soporta. 


2.14.  Resumen 


El  análisis  y  diseño  de  software  juega  un  papel  crucial  en  cualquier 
desarrollo,  pero  es  en  la  programación  orientada  a  objeto  donde  las 
actividades  relacionadas  con  esta  fase  de  un  proyecto  han  alcanzado 
sus  cotas  más  altas  de  sofisticación.  Es,  además,  un  área  donde  con¬ 
tinuamente  se  producen  avances  y  nuevas  propuestas. 

En  este  capítulo  hemos  empezado  dando  al  estudiante  una  visión  ge¬ 
neral  del  paradigma  de  programación  orientada  a  objeto,  donde 
hemos  repasado  desde  los  conceptos  más  básicos  hasta  llegar  a  to¬ 
dos  los  tipos  de  relaciones  entre  objetos  que  soportan  la  mayoría  de 
lenguajes  de  programación. 

Esta  introducción  ha  sido  necesaria  para  poder  centrarnos  a  conti¬ 
nuación  en  el  lenguaje  de  modelado  UML  y  lo  que  éste  puede  apor¬ 
tar  a  lo  largo  de  todas  las  fases  del  ciclo  de  vida  de  un  proyecto. 
Cada  uno  de  los  diagramas  se  ha  estudiado  en  detalle  a  partir  de  un 
caso  práctico. 

Aunque  la  mayoría  de  los  diagramas  de  UML  nos  permiten  mejorar  la 
comunicación  con  el  cliente  en  las  fases  iniciales,  así  como  documentar 
y  explorar  funcionalidades  y  aspectos  concretos  de  las  clases  de  nuestro 
sistema  durante  su  análisis  y  diseño,  también  hemos  visto  cómo  UML 
puede  ayudarnos  en  las  fases  de  desarrollo  e  implantación. 

Hemos  dedicado  el  último  apartado  a  la  generación  de  código  me¬ 
diante  las  tres  mismas  herramientas  de  código  abierto  que  hemos 
utilizado  en  el  material  para  generar  los  diagramas,  demostrando 
así  que  UML  en  particular  y  el  modelado  en  general  es  una  muy  bue¬ 
na  práctica  en  cualquier  proyecto,  no  sólo  por  la  disciplina  que  nos 
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impone  en  su  diseño  sino  también  por  el  ahorro  de  tiempo  en  el  de¬ 
sarrollo  que  puede  aportar. 

Por  todo  ello,  creemos  que  con  la  lectura  de  este  capítulo  el  estudian¬ 
te  habrá  logrado  los  objetivos  planteados  al  inicio  del  mismo. 

Este  material  no  pretende  ser  la  referencia  última  de  UML  para  el  es¬ 
tudiante,  sino  una  visión  global  de  este  estándar  de  modelado,  una 
motivación  para  explorar  las  referencias  que  proporcionamos  y  un  in¬ 
centivo  para  poner  en  práctica  los  conocimientos  y  buenas  prácticas 
que  hemos  indicado  en  los  próximos  proyectos  en  los  que  participe. 
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3.  Control  de  calidad  y  pruebas 


3.1 .  Introducción 

La  calidad  del  software  es  una  preocupación  a  la  que  se  dedican  mu¬ 
chos  esfuerzos.  Sin  embargo,  el  software  casi  nunca  es  perfecto. 
Todo  proyecto  tiene  como  objetivo  producir  el  software  de  la  mejor 
calidad  posible,  que  cumpla,  y  si  puede  ser  supere,  las  expectativas 
de  sus  usuarios.  Existe  abundante  literatura  sobre  los  procesos  de  ca¬ 
lidad  de  software  y  actualmente  se  realiza  una  considerable  investi¬ 
gación  académica  en  este  campo  dentro  de  la  ingeniería  del 
software. 

En  este  capítulo  intentaremos  dar  una  visión  práctica  de  los  controles 
de  calidad  y  de  pruebas  en  el  caso  particular,  tanto  de  prácticas 
como  de  aplicaciones,  del  software  libre,  y  veremos  cuáles  son  los 
principales  principios,  técnicas  y  aplicaciones  que  se  utilizan  para  ga¬ 
rantizar  la  calidad  de  los  productos  libres. 


3.2.  Objetivos 

Los  materiales  didácticos  asociados  a  este  módulo  permitirán  al  es¬ 
tudiante  obtener  los  siguientes  conocimientos: 

•  Familiarizarse  con  la  terminología  relacionada  con  el  control  de  ca¬ 
lidad  y  pruebas  que  es  de  uso  común  en  la  ingeniería  del  software. 

•  Conocer  las  principales  técnicas  de  comprobación  manual  de 
software  usadas  en  la  ingeniería  del  software  y  en  entornos  libres. 


Conocer  las  principales  técnicas  de  comprobación  automática  de 
software  usadas  en  ingeniería  del  software  y  el  software  libre  que 
se  utiliza  en  ellas. 
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•  Conocer  los  sistemas  de  comprobación  de  unidades  de  software 
y  entender  su  funcionamiento. 

•  Conocer  los  sistemas  de  gestión  de  errores,  la  anatomía  de  un 
error,  su  ciclo  de  vida,  y  familiarizarse  con  el  sistema  de  gestión 
de  errores  libre  Bugzilla. 


3.3.  Control  de  calidad  y  pruebas 


Lectura  recomendada 


M.A.  Cusumano.  Preliminary 
Data  from  Global  Software 
Process  Survey. 


Cualquier  usuario  o  desarrollador  sabe,  por  experiencia  propia,  que  los 
programas  no  son  perfectos.  Los  programas  tienen  errores.  Cuanto  me¬ 
jor  sea  el  proceso  de  ingeniería  del  software  y  el  proceso  de  control  de 
calidad  y  pruebas  que  se  utilice,  menos  errores  tendrá.  El  software  tiene 
una  media  de  0,150  errores  por  cada  1 .000  líneas  de  código.  Si  tene¬ 
mos  en  cuenta  que  un  producto  como  OpenOffice.org  1.0  tiene 
aproximadamente  7  millones  de  líneas  de  código,  la  aritmética  es 
sencilla. 


Hoy  en  día  cualquier  proyecto  de  software  integra  dentro  de  su  ciclo 
de  desarrollo  procesos  de  control  de  calidad  y  pruebas.  No  existe 
una  única  práctica  unánimemente  aceptada,  ni  el  mundo  académico 
ni  empresarial  para  llevar  a  cabo  estos  procesos.  Tampoco  existe 
ningún  método  que  se  considere  mejor  que  los  otros.  Cada  proyecto 
de  software  utiliza  la  combinación  de  métodos  que  mejor  se  adapta 
a  sus  necesidades. 


Los  proyectos  que  no  integran  un  control  de  calidad  como  parte  de 
su  ciclo  de  desarrollo  a  la  larga  tienen  un  coste  más  alto.  Esto  es  de¬ 
bido  a  que  cuanto  más  avanzado  está  el  ciclo  de  desarrollo  de  un 
programa,  más  costoso  resulta  solucionar  sus  errores.  Se  requieren 
entonces  un  mayor  número  de  horas  de  trabajo  dedicadas  a  solucio¬ 
nar  dichos  errores  y  además  sus  repercusiones  negativas  serán  más 
graves.  Por  esto,  siempre  que  iniciemos  el  desarrollo  de  un  nuevo 
proyecto  deberíamos  incluir  un  plan  de  gestión  de  calidad. 

Para  poder  llevar  a  cabo  un  control  de  calidad,  es  imprescindible  ha¬ 
ber  definido  los  requisitos  del  sistema  de  software  que  vamos  a  imple- 
mentar,  ya  que  son  necesarios  para  disponer  de  una  especificación  del 

136 


propósito  del  software.  Los  procesos  de  calidad  verifican  que  el  soft¬ 
ware  cumple  con  los  requisitos  que  definimos  originalmente. 

3.3.1.  Términos  comunes 

Las  técnicas  y  sistemas  de  control  de  calidad  y  pruebas  tienen  una 
terminología  muy  específica  para  referirse  a  conceptos  singulares  de 
este  tipo  de  sistemas.  A  continuación  veremos  los  conceptos  y  térmi¬ 
nos  más  habituales: 

•  Error  (bug).  Fallo  en  la  codificación  o  diseño  de  un  sistema  que 
causa  que  el  programa  no  funcione  correctamente  o  falle. 

•  Alcance  del  código  (coc/e  coverage).  Proceso  para  determinar 
qué  partes  de  un  programa  nunca  son  utilizadas  o  que  nunca  son 
probadas  como  parte  del  proceso  de  pruebas. 

•  Prueba  de  estrés  ( stress  testlng).  Conjunto  de  pruebas  que  tienen 
como  objetivo  medir  el  rendimiento  de  un  sistema  bajo  cargas 
elevadas  de  trabajo.  Por  ejemplo,  si  una  determinada  aplicación 
web  es  capaz  de  satisfacer  con  unos  estándares  de  servicio  acep¬ 
tables  un  número  concreto  de  usuarios  simultáneos. 

•  Prueba  de  regresión  (regression  testlng).  Conjunto  de  pruebas  que 
tienen  como  objetivo  comprobar  que  la  funcionalidad  de  la  aplica¬ 
ción  no  ha  sido  dañada  por  cambios  recientes  que  hemos  realiza¬ 
do.  Por  ejemplo,  si  hemos  añadido  una  nueva  funcionalidad  a  un 
sistema  o  corregido  un  error,  comprobar  que  estas  modificaciones 
no  han  dañado  al  resto  de  funcionalidad  existente  del  sistema. 

•  Prueba  de  usabilidad  ( usabllity  testing ).  Conjunto  de  pruebas  que 
tienen  como  objetivo  medir  la  usabilidad  de  un  sistema  por  parte 
de  sus  usuarios.  En  general,  se  centra  en  determinar  si  los  usua¬ 
rios  de  un  sistema  son  capaces  de  conseguir  sus  objetivos  con  el 
sistema  que  es  objeto  de  la  prueba. 

•  Testeador  (tester).  Persona  encargada  de  realizar  un  proceso  de 
pruebas,  bien  manuales  o  automáticas,  de  un  sistema  y  reportar 
sus  posibles  errores. 
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3.3.2.  Principios  de  la  comprobación  de  software 


Cualquiera  que  sea  la  técnica  o  conjunto  de  técnicas  que  utilicemos 
para  asegurar  la  calidad  de  nuestro  software,  existen  un  conjunto  de 
principios  que  debemos  tener  siempre  presentes.  A  continuación  enu¬ 
meramos  los  principales: 


•  Es  imperativo  disponer  de  unos  requisitos  que  detallen  el  siste¬ 
ma.  Los  procesos  de  calidad  se  basan  en  verificar  que  el  software 
cumple  con  los  requisitos  del  sistema.  Sin  unos  requisitos  que  des¬ 
criban  el  sistema  de  forma  clara  y  detallada,  es  imposible  crear 
un  proceso  de  calidad  con  unas  mínimas  garantías. 


•  Los  procesos  de  calidad  deben  ser  integrados  en  las  primeras 
fases  del  proyecto.  Los  procesos  de  control  de  calidad  del  siste¬ 
ma  deben  ser  parte  integral  del  mismo  desde  sus  inicios.  Reali¬ 
zar  los  procesos  de  pruebas  cuando  el  proyecto  se  encuentra  en 
una  fase  avanzada  de  su  desarrollo  o  cerca  de  su  fin  es  una 
mala  práctica  en  ingeniería  del  software.  Por  ejemplo,  en  el  ciclo 
final  de  desarrollo  es  muy  costoso  corregir  errores  de  diseño. 
Cuanto  antes  detectemos  un  error  en  el  ciclo,  más  económico 
será  corregirlo. 


•  Quien  desarrolle  un  sistema  no  debe  ser  quien  prueba  su  fun¬ 
cionalidad.  La  persona  o  grupo  de  personas  que  realizan  el  de¬ 
sarrollo  de  un  sistema  no  deben  ser  en  ningún  caso  las  mismas 
que  son  responsables  de  realizar  el  control  de  pruebas.  De  la  mis¬ 
ma  manera  que  sucede  en  otras  disciplinas,  como  por  ejemplo  la 
escritura,  donde  los  escritores  no  corrigen  sus  propios  textos.  Es 
importante  recordar  que  a  menudo  se  producen  errores  en  la  in¬ 
terpretación  de  la  especificación  del  sistema  y  una  persona  que 
no  ha  estado  involucrada  con  el  desarrollo  del  sistema  puede  más 
fácilmente  evaluar  si  su  interpretación  ha  sido  o  no  correcta. 


Es  importante  tomar  en  consideración  todos  estos  principios  básicos 
porque  el  incumplimiento  de  alguno  de  ellos  se  traduce  en  la  impo¬ 
sibilidad  de  poder  garantizar  la  corrección  de  los  sistemas  de  control 
de  calidad  que  aplicamos. 
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3.4.  Técnicas  manuales  de  comprobación 
de  software 

Las  técnicas  manuales  de  comprobación  de  software  son  un  conjunto 
de  métodos  ampliamente  usados  en  los  procesos  de  control  de  prue¬ 
bas.  En  su  versión  más  informal  consisten  en  un  grupo  de  testeadores 
que  instalan  una  aplicación  y,  sin  ningún  plan  predeterminado,  la 
utilizan  y  reportan  los  errores  que  van  encontrando  durante  su  uso 
para  que  sean  solucionados. 

En  la  versión  más  formal  de  este  método  se  utilizan  guiones  de  prue¬ 
bas,  que  son  pequeñas  guías  de  acciones  que  un  testeador  debe 
efectuar  y  los  resultados  que  debe  obtener  si  el  sistema  está  funcio¬ 
nando  correctamente.  Es  habitual  en  muchos  proyectos  que  antes  de 
liberar  una  nueva  versión  del  proyecto  deba  superarse  con  satisfac¬ 
ción  un  conjunto  de  estos  guiones  de  pruebas. 


La  mayoría  de  guiones  de  pruebas  tienen  como  objetivo  asegurar 
que  la  funcionalidad  más  común  del  programa  no  se  ha  visto  afec¬ 
tada  por  las  mejoras  introducidas  desde  la  última  versión  y  que  un 
usuario  medio  no  encontrará  ningún  error  grave. 


Ejemplo 

Este  es  un  ejemplo  de  guión  de  pruebas  del  proyecto 
OpenOffice.org  que  ilustra  su  uso. 

Área  de  la  prueba:  Solaris  -  Linux  -  Windows 
Objetivo  de  la  prueba 

Verificar  que  OpenOffice.org  abre  un  fichero  .¡pg  co¬ 
rrectamente 

Requerimientos: 

Un  fichero  .¡pg  es  necesario  para  poder  efectuar  esta 
prueba 

Acciones 

Descripción: 

1 )  Desde  la  barra  de  menús,  seleccione  File  -  Open. 
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2)  La  caja  de  diálogo  de  abertura  de  ficheros  debe  mos¬ 
trarse. 

3)  Introduzca  el  nombre  del  fichero  .¡pg  y  seleccione  el 
botón  Open. 

4)  Cierre  el  fichero  gráfico. 

Resultado  esperado: 

OpenOffice.org  debe  mostrar  una  nueva  ventana  mos¬ 
trando  el  fichero  gráfico. 

Fuente:  Ejemplo  de  guión  de  pruebas  extraído  del  pro¬ 
yecto  OpenOffice.org.  http://qa.openoffice.org/ 


Como  vemos,  se  trata  de  una  descripción  de  acciones  que  el  testeador 
debe  seguir,  ¡unto  con  el  resultado  esperado  para  dichas  acciones. 

Aunque  este  sistema  hoy  en  día  se  usa  ampliamente  en  combinación 
con  otros  sistemas,  confiar  el  control  de  calidad  únicamente  a  un 
proceso  de  pruebas  manuales  es  bastante  arriesgado  y  no  ofrece  ga¬ 
rantías  sólidas  de  la  calidad  del  producto  que  hemos  producido. 


3.5.  Técnicas  automáticas  de  comprobación 
de  software 


3.5.1 .  White-box  festina 

El  white-box  testing  es  un  conjunto  de  técnicas  que  tienen  como  ob¬ 
jetivo  validar  la  lógica  de  la  aplicación.  Las  pruebas  se  centran  en 
verificar  la  estructura  interna  del  sistema  sin  tener  en  cuenta  los  re¬ 
quisitos  del  mismo. 

Existen  varios  métodos  en  este  conjunto  de  técnicas,  los  más  habitua¬ 
les  son  la  inspección  del  código  de  la  aplicación  por  parte  de  otros 
desarrolladores  con  el  objetivo  de  encontrar  errores  en  la  lógica  del 
programa,  código  que  no  se  utiliza  ( code  coverage  en  inglés)  o  la  es¬ 
tructura  interna  de  los  datos.  Existen  también  aplicaciones  propieta¬ 
rias  de  uso  extendido  que  permiten  automatizar  todo  este  tipo  de 
pruebas,  como  PureCoverge  de  Rational  Software. 
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3.5.2.  Black-box  festina 


El  black-box  testing  se  basa  en  comprobar  la  funcionalidad  de  los 
componentes  de  una  aplicación.  Determinados  datos  de  entrada  a 
una  aplicación  o  componente  deben  producir  unos  resultados  deter¬ 
minados.  Este  tipo  de  prueba  está  dirigida  a  comprobar  los  resulta¬ 
dos  de  un  componente  de  software  no  a  validar  como  internamente 
ha  sido  estructurado.  Se  llama  black  box  (caja  negra)  porque  el  pro¬ 
ceso  de  pruebas  asume  que  se  desconoce  la  estructura  interna  del 
sistema,  sólo  se  comprueba  que  los  datos  de  salida  producidos  por 
una  entrada  determinada  son  correctos. 


Imaginemos  que  tenemos  un  sistema  orientado  a  objetos  donde  exis¬ 
te  una  clase  de  manipulación  de  cadenas  de  texto  que  permite  con¬ 
catenar  cadenas,  obtener  su  longitud,  y  copiar  fragmentos  a  otras 
cadenas.  Podemos  crear  una  prueba  que  se  base  en  realizar  varias 
operaciones  con  cadenas  predeterminadas:  concatenación,  medir  la 
longitud,  fragmentarlas,  etc.  Sabemos  cuál  es  el  resultado  correcto 
de  estas  operaciones  y  podemos  comprobar  la  salida  de  esta  rutina. 
Cada  vez  que  ejecutamos  la  prueba,  la  clase  obtiene  como  entradas 
estas  cadenas  conocidas  y  comprueba  que  las  operaciones  realiza¬ 
das  han  sido  correctas. 


Este  tipo  de  tests  son  muy  útiles  para  asegurar  que  a  medida  que  el 
software  va  evolucionando  no  se  rompe  la  funcionalidad  básica  del 
mismo. 


3.5.3.  Unidades  de  comprobación 

Cuando  trabajamos  en  proyectos  de  una  cierta  dimensión,  necesita¬ 
mos  tener  procedimientos  que  aseguren  la  correcta  funcionalidad  de 
los  diferentes  componentes  del  software,  y  muy  especialmente,  de  los 
que  forman  la  base  de  nuestro  sistema.  La  técnica  de  las  unidades 
de  comprobación,  unlt  testing  en  inglés,  se  basa  en  la  comprobación 
sistemática  de  clases  o  rutinas  de  un  programa  utilizando  unos  datos 
de  entrada  y  comprobando  que  los  resultados  generados  son  los  es¬ 
perados.  Hoy  en  día,  las  unidades  de  comprobación  son  la  técnica 
black  boxing  más  extendida. 
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Una  unidad  de  prueba  bien  diseñada  debe  cumplir  los  siguientes  re¬ 
quisitos: 

•  Debe  ejecutarse  sin  atención  del  usuario  (desatendida).  Una 

unidad  de  pruebas  debe  poder  ser  ejecutada  sin  ninguna  inter¬ 
vención  del  usuario:  ni  en  la  introducción  de  los  datos  ni  en  la 
comprobación  de  los  resultados  que  tiene  como  objetivo  determi¬ 
nar  si  la  prueba  se  ha  ejecutado  correctamente. 

•  Debe  ser  universal.  Una  unidad  de  pruebas  no  puede  asumir 
configuraciones  particulares  o  basar  la  comprobación  de  resulta¬ 
dos  en  datos  que  pueden  variar  de  una  configuración  a  otra. 
Debe  ser  posible  ejecutar  la  prueba  en  cualquier  sistema  que  ten¬ 
ga  el  software  que  es  objeto  de  la  prueba. 

•  Debe  ser  atómica.  Una  unidad  de  prueba  debe  ser  atómica  y  te¬ 
ner  como  objetivo  comprobar  la  funcionalidad  concreta  de  un 
componente,  rutina  o  clase. 

Dos  de  los  entornos  de  comprobación  más  populares  en  entornos  de 
software  libre  con  JUnit  y  NUnit.  Ambos  entornos  proporcionan  la  in¬ 
fraestructura  necesaria  para  poder  integrar  las  unidades  de  compro¬ 
bación  como  parte  de  nuestro  proceso  de  pruebas.  JUnit  está 
pensado  para  aplicaciones  desarrolladas  en  entorno  Java  y  NUnit 
para  aplicaciones  desarrolladas  en  entorno  .Net.  Es  habitual  el  uso 
del  término  xUnit  para  referirse  al  sistema  de  comprobación  inde¬ 
pendientemente  del  lenguaje  o  entorno  que  utilizamos. 


Ejemplo 

El  siguiente  ejemplo  es  un  fragmento  de  la  unidad  de  com¬ 
probación  de  la  clase  StringFormat  del  namespace  Sys¬ 
tem.  Drawing  del  proyecto  Mono  que  son  ejecutados  con  el 
sistema  Nunit  de  comprobación  de  unidades. 

namespace  MonoTests . System . Drawing 
{ 

[TestFixture] 

public  class  StringFormatTest 
{ 

[Test] 

public  void  TestCloneO 
{ 
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StringFormat  smf  =  new  StringFormat ( ) ; 

StringFormat  smfclone  =  (StringFormat)  smf.CloneO; 

Assert . AreEqual  (smf . LineAlignment,  smfclone . LineAlignment) ; 
Assert . AreEqual  (smf . FormatFlags,  smf clone . FormatFlags ) ; 
Assert .AreEqual  (smf .LineAlignment,  smfclone . LineAlignment) ; 
Assert .AreEqual  (smf . Alignment,  smf clone .Alignment) ; 
Assert .AreEqual  (smf . Trimming,  smfclone . Trimming) ; 


Fragmento  de  la  unidad  de  comprobación  de  la  clase  Strin¬ 
gFormat  del  proyecto  Mono 


El  método  TestClone  tiene  como  objetivo  comprobar  la  funcionalidad 
del  método  Clone  de  la  clase  StringFormat.  Este  método  realiza  una 
copia  exacta  del  objeto.  Las  pruebas  se  basan  en  asegurar  que  las 
propiedades  del  objeto  han  sido  copiadas  correctamente. 


3.6.  Sistemas  de  control  de  errores 


Los  sistemas  de  control  de  errores  son  herramientas  colaborativas 
muy  dinámicas  que  proveen  el  soporte  necesario  para  consolidar 
una  pieza  clave  en  la  gestión  del  control  de  calidad:  el  almacena¬ 
miento,  seguimiento  y  clasificación  de  los  errores  de  una  aplicación 
de  forma  centralizada.  El  uso  de  estos  sistemas  en  la  mayoría  de  pro¬ 
yectos  se  extiende  también  a  la  gestión  de  mejoras  solicitadas  por  el 
usuario  e  ideas  para  nuevas  versiones,  e  incluso,  algunos  usuarios 
los  utilizan  para  tener  un  control  de  las  llamadas  de  un  soporte  téc¬ 
nico,  pedidos,  o  los  utilizan  como  gestores  de  tareas  que  hay  que 
realizar. 


3.6.1.  Reportado  en  errores 

Cuando  un  usuario  encuentra  un  error,  una  buena  forma  de  garan¬ 
tizar  que  será  buen  candidato  a  ser  corregido  es  escribir  un  informe 
de  error  lo  más  preciso  y  detallado  posible. 
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Independientemente  de  cuál  sea  el  sistema  de  control  de  errores  que 
utilicemos,  los  siguientes  consejos  reflejan  las  buenas  prácticas  en  el 
reporte  de  errores: 

•  Comprobar  que  el  error  no  ha  sido  reportado  anteriormente. 

Suele  ocurrir  con  frecuencia  que  errores  que  los  usuarios  encuen¬ 
tran  a  menudo  son  reportados  en  más  de  una  ocasión.  Esto  causa 
que  el  número  de  errores  totales  pendientes  de  corregir  vaya  au¬ 
mentando  y  que  el  número  total  de  errores  registrados  no  refleje 
la  realidad.  Este  tipo  de  errores  se  llaman  duplicados  y  suelen  ser 
eliminados  tan  pronto  como  son  detectados.  Antes  de  reportar  un 
nuevo  error,  es  importante  hacer  una  búsqueda  en  el  sistema  de 
control  de  errores  para  comprobar  que  no  ha  sido  reportado  an¬ 
teriormente. 

•  Dar  un  buen  título  al  informe  de  error.  El  título  del  informe  de 
error  debe  ser  muy  descriptivo,  ya  que  esto  ayudará  a  los  desa¬ 
rrolladores  a  poder  valorar  el  error  cuando  hagan  listados  de  los 
mismos,  y  además,  ayudará  a  otros  usuarios  a  encontrar  errores 
ya  reportados  y  evitar  reportar  posibles  duplicados. 


Por  ejemplo,  un  título  del  tipo  "El  programa  se  cuelga"  sería  un 
ejemplo  de  un  mal  título  para  describir  un  error  por  ser  muy  poco 
descriptivo.  Sin  embargo,  "El  programa  se  cuelga  en  la  previsua- 
lización  de  imágenes"  es  mucho  más  preciso  y  descriptivo. 

•  Dar  una  descripción  detallada  y  paso  a  paso  de  cómo  reprodu¬ 
cir  el  error.  Es  importarte  que  el  error  sea  determinista  y  que  po¬ 
damos  dar  una  guía  paso  a  paso  de  cómo  reproducirlo  para  que 
la  persona  que  debe  corregirlo  pueda  hacerlo  fácilmente.  Siempre 
debemos  tener  presente  que  la  claridad  en  la  descripción  del  error 
facilita  el  trabajo  de  todos  los  involucrados  en  el  proceso. 


•  Dar  la  máxima  información  sobre  nuestra  configuración  y  sus 
particularidades.  La  mayoría  de  sistemas  de  reporte  de  error  dis¬ 
ponen  de  campos  que  permiten  especificar  nuestra  configuración 
(tipo  de  ordenador,  sistema  operativo,  etc.).  Debemos  dar  la  máxi¬ 
ma  información  sobre  las  particularidades  de  nuestra  configuración, 
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ya  que  estos  dos  datos  a  menudo  son  imprescindibles  para  solu¬ 
cionar  un  error. 

•  Reportar  un  único  error  por  informe.  Cada  informe  de  error 
que  efectuemos  debe  contener  la  descripción  de  un  único  error. 
Esto  facilita  que  el  error  pueda  ser  tratado  como  una  unidad  por 
el  equipo  de  desarrollo.  Muy  a  menudo  diferentes  módulos  de 
un  programa  están  bajo  la  responsabilidad  de  diferentes  desa¬ 
rrolladores. 


Siguiendo  todos  estos  consejos  se  mejora  la  claridad  de  nuestros  in¬ 
formes  de  error  y  nos  ayuda  a  alcanzar  el  objetivo  final  de  cualquier 
reporte  de  error,  que  es  conseguir  que  éste  pueda  ser  solucionado 
con  la  mayor  rapidez  y  el  menor  coste  posible. 


3.6.2.  Anatomía  de  un  informe  de  error 

Cualquiera  que  sea  el  sistema  de  control  de  errores  que  usemos,  to¬ 
dos  los  sistemas  detallan  el  error  con  una  serie  de  campos  que  per¬ 
miten  definirlo  y  clasificarlo  de  forma  precisa.  A  continuación 
describimos  los  principales  campos  que  forman  parte  de  un  informe 
de  error: 

•  Identificador.  Código  único  que  identifica  el  informe  de  error  de 
forma  inequívoca  y  que  asigna  el  sistema  de  forma  automática. 
Normalmente,  los  identificadores  suelen  ser  numéricos,  permi¬ 
tiéndonos  referirnos  al  error  por  su  número,  como  por  ejemplo  el 
error  3210. 

•  Título.  Frase  de  aproximadamente  unos  50  caracteres  que  descri¬ 
be  el  error  de  forma  sintética  y  le  da  un  título. 

•  Informador.  Persona  que  envía  el  informe  de  error.  Normalmen¬ 
te,  un  usuario  registrado  en  el  sistema  de  control  de  errores. 


Fecha  de  entrada.  Fecha  en  la  que  el  error  fue  registrado  en  el 
sistema  de  control  de  errores. 


145 


Estado.  Situación  en  la  que  se  encuentra  el  error.  En  el  apartado 
de  ciclo  de  vida  de  un  error,  veremos  los  diferentes  estados  por 
los  cuales  puede  pasar  un  error. 


•  Gravedad.  Indica  la  gravedad  del  error  dentro  del  proyecto.  Exis¬ 
ten  diferentes  categorías  definidas  que  abarcan  desde  un  error  tri¬ 
vial  a  un  error  que  puede  ser  considerado  grave. 


•  Palabras  clave.  Conjunto  de  palabras  clave  que  podemos  usar 
para  definir  el  error.  Por  ejemplo,  podemos  usar  crash  para  indi¬ 
car  que  es  un  error  que  tiene  como  consecuencia  que  el  programa 
se  cuelgue.  Esto  es  muy  útil  porque  luego  permite  a  los  desarrolla¬ 
dores  hacer  listados  o  búsquedas  por  estas  palabras  clave. 


•  Entorno.  Normalmente  existen  uno  o  más  campos  que  permiten 
definir  el  entorno  y  configuración  del  usuario  donde  se  produce  el 
error.  Algunos  sistemas,  como  Bugzilla,  tienen  campos  que  per¬ 
miten  especificar  la  información  por  separado,  como  por  ejem¬ 
plo:  sistema  operativo,  arquitectura  del  sistema,  etc. 


•  Descripción.  Una  descripción  del  error  y  cómo  reproducirlo.  Al¬ 
gunos  sistemas  permiten  que  diferentes  usuarios  puedan  ir  am¬ 
pliando  la  información  del  error  a  medida  que  el  ciclo  de  vida  del 
error  avanza  con  detalles  relacionados  con  su  posible  solución,  su 
implicación  para  otros  errores,  o  simplemente  para  concluir  que 
el  error  ha  sido  solucionado. 


Éstos  son  los  campos  que  podemos  considerar  los  mínimos  comunes 
a  todos  los  sistemas  de  control  de  errores.  Cada  sistema  añade  cam¬ 
pos  adicionales  propios  para  ampliar  esta  información  básica  o  per¬ 
mitir  realizar  funciones  avanzadas  propias. 


3.6.3.  Ciclo  de  vida  de  un  error 
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El  ciclo  de  vida  de  un  error  comienza  cuando  es  reportado  y  fina¬ 
liza  cuando  el  error  se  soluciona.  Entre  estos  extremos  del  ciclo  de 


vida  existen  una  serie  de  estados  por  los  cuales  va  pasando  el 
error. 


Aunque  no  hay  un  estándar  definido  entre  los  diferentes  sistemas  de 
control  de  errores,  utilizaremos  la  terminología  que  utiliza  el  sistema 
Bugzilla,  ya  que  es  el  más  extendido  dentro  del  mundo  del  software 
libre. 


Éstos  son  los  principales  estados  en  los  que  se  puede  encontrar  un 
error  durante  su  ciclo  de  vida  con  Bugzilla: 


•  Sin  confirmar.  Se  produce  cuando  el  informe  de  error  ha  sido  in¬ 
troducido  en  el  sistema.  Es  el  estado  inicial  por  el  que  pasa  cual¬ 
quier  error. 


•  Nuevo.  El  error  estaba  en  estado  "Sin  Confirmar"  y  se  ha  com¬ 
probado  su  validez  y  ha  pasado  al  estado  "Nuevo",  que  represen¬ 
ta  que  ha  sido  aceptado  formalmente  como  error. 


•  Asignado.  El  error  ha  sido  asignado  a  un  desarrollador  para  que 
lo  solucione.  Ahora  debemos  esperar  a  que  el  desarrollador  ten¬ 
ga  tiempo  para  poder  evaluar  el  error  y  solucionarlo. 


•  Corregido.  El  error  ha  sido  corregido  y  debería  estar  solucionado. 


•  Cerrado.  El  error  ha  sido  corregido  y  ha  confirmado  la  solución 
como  correcta.  Éste  es  el  fin  de  ciclo  de  vida  del  error. 


•  Inválido.  El  error  no  era  un  error  válido  o  simplemente  no  era  un 
error.  Por  ejemplo,  cuando  se  describe  una  funcionalidad  que  es 
correcta. 


A  continuación  vamos  a  ver  un  esquema  que  ilustra  los  principales 
estados,  Bugzilla  y  otros  sistemas  disponen  de  estados  adicionales  en 
los  que  puede  estar  un  error  durante  su  ciclo  de  vida. 
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Figura  1 .  Principales  estados  en  los  que  puede 
estar  un  error  durante  su  ciclo  de  vida 


Podemos  observar  que  cuando  un  error  entra  en  el  sistema  queda 
clasificado  como  "Sin  Confirmar".  Una  vez  es  revisado,  puede  des¬ 
cartarse  como  error  y  marcarse  como  "Inválido"  para  luego  "Cerrar" 
el  error.  Si  el  error  es  aceptado  como  "Nuevo",  el  siguiente  paso  es 
asignarlo  a  un  desarrollador,  que  es  un  usuario  en  el  sistema  de  con¬ 
trol  de  errores.  Una  vez  está  asignado,  el  error  es  corregido,  y  una 
vez  verificado,  es  cerrado. 


Lectura  recomendada 


j  http://www.bugzilla.org/ 


3.6.4.  Buqzilla 

Un  aspecto  central  en  cualquier  proyecto  de  software  es  la  gestión  y  el 
seguimiento  de  los  errores.  Cuando  Netscape  en  1998  liberó  el  códi¬ 
go  de  Mozilla,  se  encontró  con  la  necesidad  de  tener  una  aplicación 
de  gestión  de  errores  vía  web  que  permitiera  la  interacción  entre  usua¬ 
rios  y  desarrolladores.  Decidieron  adaptar  la  aplicación  que  usaban 
internamente  en  Netscape  a  las  necesidades  de  un  proyecto  abierto  y 
así  nació  Bugzilla.  Inicialmente,  fue  el  sistema  de  gestión  y  seguimiento 
de  errores  del  proyecto  Mozilla,  pero  con  el  tiempo  ha  sido  adoptado 
por  muchos  proyectos  libres,  incluyendo  KDE  y  GNOME,  entre  otros. 
Bugzilla  permite  a  los  usuarios  enviar  errores  facilitando  la  clasifica¬ 
ción  del  error,  su  asignación  a  un  desarrollador  para  que  lo  resuelva 
y  todo  el  seguimiento  de  las  incidencias  relacionadas. 
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Entre  las  características  que  provee  Bugzilla,  destacan  las  siguientes: 


•  Interfaz  web.  Una  completa  interfaz  web  que  permite  que  cual¬ 
quier  persona  con  un  simple  navegador  pueda  enviarnos  un  error 
o  administrar  el  sistema. 


•  Entorno  colaborativo.  Cada  reporte  de  error  se  convierte  en  un 
hilo  de  discusión  donde  usuarios,  probadores  y  desarrolladores 
pueden  discutir  sobre  las  implicaciones  de  un  error,  su  posible  ori¬ 
gen  o  cómo  corregirlo. 


•  Notificación  por  correo.  Bugzilla  permite  notificar  por  correo  a  los 
usuarios  de  diferentes  eventos,  como  por  ejemplo  informar  a  los 
usuarios  involucrados  en  un  error  concreto  de  cambios  en  el  mismo. 


•  Sistema  de  búsquedas.  El  sistema  de  búsquedas  es  muy  comple¬ 
to,  permitiéndonos  buscar  errores  por  su  tipo,  por  quién  informó 
de  ellos,  por  la  prioridad  que  tienen  o  por  la  plataforma  en  que 
han  surgido. 


•  Informes.  Tiene  integrado  un  completo  sistema  que  permite  ge¬ 
nerar  informes  sobre  el  estado  de  los  errores  del  proyecto. 


•  Votaciones.  Bugzilla  permite  la  votación  de  los  errores  pudiéndo¬ 
se  así  establecer  prioridades  para  su  resolución  basándose  en  los 
votos  que  han  recibido  de  usuarios. 


•  Seguro.  Contempla  registro  de  usuarios,  diferentes  niveles  de  se¬ 
guridad  y  una  arquitectura  diseñada  para  preservar  la  privacidad 
de  sus  usuarios. 
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Figura  2.  Captura  de  pantalla  del  sistema  de  control 
de  errores  Bugzilla 
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3.6.5.  Gnats 


Gnats  (GNU  problem  report  management  system )  es  la  herramienta 
de  gestión  de  errores  para  entornos  Unix  desarrollada  por  la  Free 
Software  Foundation  a  principios  de  los  años  noventa.  Es  más  anti¬ 
gua  que  Bugzilla.  Gnats  es  usado  por  proyectos  como  FreeBSD  o 
Apache,  y  lógicamente,  por  los  proyectos  impulsados  por  la  propia 
Free  Software  Foundation. 


El  núcleo  de  Gnats  es  un  conjunto  de  herramientas  de  línea  de  co¬ 
mandos  que  exponen  toda  la  funcionalidad  del  sistema.  Tiene  todas 
las  ventajas  y  flexibilidad  de  las  herramientas  GNU,  pero  su  uso  pue¬ 
de  resultar  difícil  a  los  que  no  estén  familiarizados  con  este  tipo  de 
herramientas.  Existe  también  una  interfaz  web  que  fue  desarrollada 
posteriormente  y  es  el  front-end  más  usado  hoy  en  día. 
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Figura  3.  Captura  de  pantalla  del  sistema  de  control 
de  errores  Gnat 


3.7.  Conclusiones 


Durante  este  capítulo  hemos  constatado  la  necesidad  de  integrar  los 
procesos  de  control  de  calidad  y  pruebas  dentro  del  ciclo  de  desarro¬ 
llo  de  un  programa  desde  el  inicio  del  mismo.  Hemos  visto  los  prin¬ 
cipios  que  rigen  la  comprobación  del  software,  la  escritura  de  un 
buen  informe  de  error  y  de  una  unidad  de  comprobación. 


También  hemos  conseguido  una  visión  práctica  de  los  sistemas  de 
control  de  calidad  y  pruebas  en  el  caso  particular,  tanto  de  prácticas 
como  de  aplicaciones  del  software  libre  y  hemos  visto  cuáles  son  los 
principales  principios,  técnicas  y  aplicaciones  que  se  utilizan  para  ga¬ 
rantizar  la  calidad  de  los  productos  libres. 
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4.  Construcción  de  software  en  entorno  GNU 


4.1 .  Introducción 

El  sistema  operativo  GNU/Linux  ha  supuesto  una  auténtica  revolución 
en  el  mundo  del  software  libre.  Como  consecuencia  de  su  expansión, 
el  desarrollo  de  software  en  entornos  GNU  se  ha  multiplicado  por  diez 
en  el  último  año  (2004).  Gran  cantidad  de  compañías  que  desarrolla¬ 
ban  sus  productos  en  entorno  propietario  migran  estos  a  plataformas 
libres,  lo  que  demanda  un  gran  número  de  programadores  en  un  en¬ 
torno  muy  distinto  al  habitual  en  el  software  propietario. 


4.2.  Objetivos 

Este  capítulo  pretende  al  programador  lo  siguiente: 

•  Poder  introducirse  en  el  entorno  de  desarrollo  GNU  guiándole  no 
sólo  en  la  instalación  de  los  componentes  necesarios  para  comenzar 
a  desarrollar,  sino  en  la  creación  de  los  ficheros  de  configuración  y 
en  el  reconocimiento  de  los  generados  tras  una  compilación,  a  man¬ 
tener  estos  ficheros,  a  documentar  el  código  y  sus  cambios,  así  co¬ 
mo,  a  usar  las  librerías  y  las  utilidades  relacionadas  con  éstas. 


4.3.  Instalando  todo  lo  necesario.  Autotools 


Las  autotools  son  un  conjunto  de  utilidades  para  automatizar  la  com¬ 
pilación  de  programas  en  diferentes  entornos.  Permiten  al  desarro¬ 
llador  especificar  unas  reglas  generales  para  la  compilación  y  que  el 
resto  de  la  configuración  sea  detectado  en  la  máquina  destino,  sim¬ 
plificando  la  tarea  de  portabilidad  entre  sistemas  y  en  general  la 
creación  de  ficheros  Makefile  de  un  proyecto. 
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En  realidad  se  componen  de  dos  paquetes: 

http://directory.fsf.org/GNU/autoconf.html 

http://directory.fsf.org/GNU/automake.html 

Ambos  están  interrelacionados  entre  sí  y  necesitan  un  intérprete  de 
Perl  y  de  macros  m4. 

La  estructura  de  funcionamiento  es  la  siguiente: 


1 )  automake  traduce  un  fichero  de  configuración  Makefile.am  y  ge¬ 
nera  un  Makefile . in. 


2)  autoconf  procesa  un  configure  .  in  (o  configure  .  ac)  y 
genera  ./configure. 


3)  En  la  máquina  destino  se  ejecuta  ./configure  que  genera 
los  Makefile  y  opcionalmente  otros  archivos,  posiblemente  en 
todos  los  directorios  que  haga  falta. 


4.3.1.  Fichero  de  configuración  de  usuario  finpuf) 

Un  proyecto  de  software  constará  de  una  serie  de  ficheros  con  código 
fuente  y  una  serie  de  pasos  a  dar  para  convertirlos  en  programa  eje¬ 
cutable. 

Estos  pasos,  bajo  autotools,  se  dividen  en  dos  partes  principales: 


1 )  Por  un  lado,  un  fichero  Makefile  .  am  a  partir  del  cual  se  creará  el 
Makefile  final  siguiendo  el  cual  será  compilado  el  código  fuente. 


2)  Por  otro,  un  fichero  configure,  in  o  configure,  ac  que 
servirá  de  plantilla  para  crear  un  fichero  de  script  de  shell  con  los 
pasos  necesarios  para  detectar  y  establecer  la  configuración  ne¬ 
cesaria  para  que  el  programa  sea  compilado  e  instalado  sin  pro¬ 
blemas.  También  será  el  encargado  de  crear  los  Makefile 
necesarios  siguiendo  el  Makefile  .  am  inicial. 
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Sin  embargo,  incluso  estos  pasos  se  pueden  automatizar  con  la  utilidad 
autoscan,  que  generará  un  configure .  ac  preliminar,  con  el  nombre 
de  configure  .sean,  basándose  en  los  ficheros  de  código  fuente  que 
encuentre  en  el  directorio  (y  subdirectorios)  donde  se  ejecute. 

Veamos  este  funcionamiento  con  un  programa  de  ejemplo  extrema¬ 
damente  simple: 

nul .  c 

void  main ( )  { } 

Creamos  un  Makef  ile  .  am  sencillo: 


Makefile . am 

bin_PROGRAMS  =  nul 
nul_SOURCES  =  nul .  c 

En  este  ejemplo  sólo  crearemos  un  binario  nul  a  partir  del  fichero 
de  código  fuente  nul .  c. 

Simplemente  ejecutando  autoscan  obtendremos  un  fichero  con¬ 
figure  .  ac  base: 


configure . sean 

AC_PREREQ (2.59) 

AC_INIT (FULL-PACKAGE-NAME,  VERSION,  BUG-REPORT-ADDRESS ) 
AC_CONFIG_SRCDIR( [nul.c] ) 

AC_CONFIG_HEADER( [config.h] ) 

#  Checks  for  programs. 

AC_PROG_CC 

AC_CONFIG_FILES ( [Makefile] ) 

AC_OUTPUT 

Este  fichero  es  recomendable  editarlo  para  adecuarlo  al  proyecto 
que  estamos  desarrollando: 

configure . ac 

AC_INIT (nul,  0.1) 

AM_INIT_AUTOMAKE (nul,  0.1) 

AC_CONFIG_SRCDIR( [nul.c] ) 

#  Checks  for  programs. 

AC_PROG_CC 

AC_CONFIG_FILES ( [Makefile] ) 

AC  OUTPUT 
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El  significado  de  este  fichero  sería: 

•  Inicializar  autoconf  (con  el  nombre  y  versión  del  programa  a 
compilar). 

•  Inicializar  automake  (otra  vez  con  nombre  y  versión). 

•  Establecer  el  directorio  origen  como  el  de  nul .  c  . 

•  Buscar  un  compilador  de  lenguaje  C. 

•  Establecer  ficheros  de  configuración  Makefile  . 

•  Generar  los  ficheros  de  salida. 

4.3.2.  Ficheros  generados  ( outout ) 

Antes  de  poder  generar  los  ficheros  de  salida  definitivos,  deberemos 
pre-configurar  las  macros  que  usarán  las  autotools,  y  ya  podremos 
ejecutar  autoconf: 

$  aclocal 
$  autoconf 
$  ls  -1 


-rw-r— r— 

1 

user 

user 

37129 

nov 

17 

18:03 

aclocal .m4 

drwxr-xr-x 

2 

user 

user 

4096 

nov 

17 

18:03 

autom4te . cache/ 

-rwxr-xr-x 

1 

user 

user 

103923 

nov 

17 

18:03 

configure* 

-rw-r— r— 

1 

user 

user 

145 

nov 

17 

18:03 

configure . ac 

-rw-r— r— 

1 

user 

user 

39 

nov 

17 

18:03 

Makefile . am 

-rw-r— r— 

1 

user 

user 

15 

nov 

17 

18:03 

nul .  c 

Podría  parecer  que  ya  está  creado  .  / configure,  sin  embargo  todavía 
tenemos  que  preparar  las  macros  de  automake  para  que  funcione: 

$  automake  --add-missing 


automake : 

configure . ac : 

:  installing 

.  /install-sh ' 

automake : 

configure . ac : 

:  installing 

. /mkinstalldirs ' 

automake : 

configure . ac : 

:  installing 

. /missing ' 

automake : 

configure . ac : 

:  installing 

.  /conf ig . guess ' 

automake : 

configure . ac : 

:  installing 

.  /conf ig . sub ' 

automake : 

Makefile . am: 

installing  ' . 

/INSTALL ' 

automake : 

Makefile . am: 

required  file 

' . /NEWS '  not  found 

automake : 

Makefile . am: 

required  file 

' . /README '  not  found 

automake : 

Makefile . am: 

installing  ' . 

/COPYING ' 

automake : 

Makefile . am: 

required  file 

' . /AUTHORS 1  not  found 

automake : 

Makefile . am: 

required  file 

' . /ChangeLog '  not  found 
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Como  se  puede  observar,  automake  ha  instalado  una  serie  de 
Scripts  necesarios  para  ejecutar  .  /configure  en  conjunción  con  au¬ 
tomake,  y  además  ha  creado  dos  ficheros  INSTALL  y  COPYING,  infor¬ 
mando  de  que  faltan  otros  cuatro. 

Veamos  lo  que  son  cada  uno  de  estos  ficheros: 

•  INSTALL:  este  fichero  describe  el  proceso  de  instalación.  Auto¬ 
make  crea  por  defecto  un  fichero  con  una  guía  de  instalación  bá¬ 
sica,  pero  será  recomendable  editarlo  para  adecuarlo  a  las 
necesidades  de  cada  proyecto  en  concreto. 

•  COPYING :  especifica  la  licencia  bajo  la  que  se  permite  o  restringe 
la  realización  de  copias  del  software  y  código  fuente  del  proyecto. 

•  NEWS:  una  lista  de  las  modificaciones  ("novedades")  del  proyecto. 
Suele  ir  ordenado  con  las  últimas  entradas  al  principio  y  de  forma 
decreciente  según  las  versiones. 

•  README:  este  fichero  suele  ser  históricamente  el  primero  en  ser  mi¬ 
rado  por  el  usuario.  Suele  incluir  una  descripción  corta  y  tal  vez  re¬ 
comendaciones  sobre  el  uso  y  otros  detalles  relativos  al  paquete. 
También  advertencias  que  puedan  evitar  problemas  al  usuario. 

•  AUTHORS:  una  lista  de  las  personas  que  han  intervenido  en  el  de¬ 
sarrollo  del  proyecto.  Suelen  incluirse  las  direcciones  de  correo  y 
posiblemente  otras  formas  de  contacto,  tanto  para  aspectos  lega¬ 
les  de  propiedad  intelectual  como  para  consultas,  sugerencias  e 
informes  de  bugs  (fallos),  aparte  del  merecido  reconocimiento  de 
cada  uno. 

•  ChangeLog:  uno  de  los  ficheros  más  importantes,  que  permitirá  co¬ 
nocer  los  cambios,  actualizaciones  y  estado  en  general  del  proyecto 
de  software  (información  adicional  en  sección  más  adelante). 

Siguiendo  con  el  ejemplo  simple,  por  ahora  rellenaremos  estos  fiche¬ 
ros  con  datos  simples: 

$  echo  '2004-11-17:  Proyecto  creado'  >  NEWS 
$  echo  'No  hace  nada.  Sintaxis:  nul '  >  README 
$  echo  'David  Aycart  <david@aycart . com> '  >  AUTHORS 
$  cat  «END  >  ChangeLog 

2004-11-17  David  Aycart  <david@aycart . com> 

*  nul.c:  creado 

END 
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o 


Ahora  ya  podremos  ejecutar  automake  sin  que  dé  error: 


$  automake  --add-missing 
$  ls 

aclocal.m4  conf ig . guess@ 

AUTHORS  config.log 

autom4 te . cache/  config.sub@ 
ChangeLog  configure* 


configure . ac 
COPYING® 
INSTALL0 
install-sh@ 


Makefile.am  NEWS 
Makefile.in  nul . c 
missing®  README 

mkinstalldirs® 


En  este  punto  ya  sería  posible  comprimir  esta  estructura  de  directorio  y 
distribuirla  como  paquete  .  tar,  o  añadir  los  ficheros  de  control  nece¬ 
sarios  y  crear  un  paquete  de  código  fuente  rpm,  deb,  o  cualquier  otro. 

Para  compilarlo  a  partir  de  este  punto  sólo  hacen  falta  ejecutar 

. /conf igure  y  después  make  all: 


$  ./configure 

checking  for  a  BSD-compatible  install...  /usr/bin/install  -c 

checking  whether  build  environment  is  sane...  yes 

checking  whether  make  sets  $ (MAKE) . . .  yes 

checking  for  working  aclocal-1 . 4 . . .  found 

checking  for  working  autoconf...  found 

checking  for  working  automake-1 . 4 . . .  found 

checking  for  working  autoheader . . .  found 

checking  for  working  makeinfo...  found 

checking  for  gcc...  gcc 

checking  for  C  compiler  default  output  file  ñame...  a.out 

checking  whether  the  C  compiler  works...  yes 

checking  whether  we  are  cross  compiling. . .  no 

checking  for  suffix  of  executables . . . 

checking  for  suffix  of  object  files...  o 

checking  whether  we  are  using  the  GNU  C  compiler...  yes 

checking  whether  gcc  accepts  -g. . .  yes 

checking  for  gcc  option  to  accept  ANSI  C...  none  needed 
configure:  creating  . /conf ig . status 
conf ig . status :  creating  Makefile 


$  make  all 

gcc  -DPACKAGE_NAME=\ "nul\ "  -DPACKAGE_TARNAME=\ "nul\ "  -DPACKAGE_VERSION=\"0 . l\"-DPACKAGE_STRING=\"nul\ 
0.1\"  -DPACKAGE_BUGREPORT=\ " \ "  -DPACKAGE=\ "nul\"  -DVERSION=\ " 0 . 1 \ "  -I.  -I.  -g  -02  -c  nul . c 

nul.c:  In  function  'main': 

nul.cil:  warning:  return  type  of  'main*  is  not  ' int ' 
gcc  -g  -02  -o  nul  nul. o 


$  ls  -1  nul 

-rwxr-xr-x  1  user  user  7893  nov  17  17:03  nul 
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4.3.3.  Como  mantener  ficheros  de  entrada 


Si  se  edita  alguno  de  los  ficheros  de  entrada  de  las  autotools,  esto  es 
configure,  ac  o  Makefile.am,  será  necesario  actualizar  los  fi¬ 
cheros  generados  por  autoconf  y  automake. 

Una  forma  es  crearse  un  script  que  repita  los  pasos  que  hemos 
dado  anteriormente  para  crear  los  ficheros.  En  este  caso  las  auto¬ 
tools  ya  traen  un  programa  que  hace  exactamente  esto,  llamado 
autoreconf.  Exactamente  lo  que  hace  es  ejecutar  una  secuencia 
estándar  de  las  utilidades  de  autotools  que  normalmente  es  sufi¬ 
ciente  para  actualizar  los  ficheros. 

De  hecho,  en  proyectos  simples  como  el  del  ejemplo  anterior  (nul .  c), 
sería  posible  ejecutar  autoreconf  directamente  después  de  crear 
configure  .  ac  y  Makef ile .  am.  En  ese  caso,  añadiendo  los  fiche¬ 
ros  de  documentación  de  cuya  falta  informaría  autoreconf  (al  ejecutar 
automake  --add-missing)  y  ejecutándolo  una  vez  más. 

4.3.4.  Empaquetar  ficheros  outout 

Una  práctica  común  en  los  paquetes  de  código  fuente  distribuidos  ¡un¬ 
to  a  las  mayores  distribuciones,  es  la  inclusión  de  todos  los  ficheros  ge¬ 
nerados  de  tal  forma  que  sea  suficiente  ejecutar  ./configure  y 
make  all  o  make  install  para  que  el  programa  sea  totalmente 
funcional  en  el  sistema  destino. 

Esto  tiene  dos  implicaciones,  una  buena  y  otra  no  tanto. 

Por  un  lado,  a  un  usuario  novel  (o  no  tan  novel)  le  facilita  mucho  la 
tarea  de  pasar  parches  y  poder  disfrutar  del  programa  corregido 
en  el  menor  tiempo  posible  sin  necesitar  mayores  conocimientos 
sobre  el  sistema. 

Por  otro,  si  estos  ficheros  fuente  se  intentasen  compilar  en  otro  siste¬ 
ma  sería  posible  que  el  fichero  ./configure  no  fuese  completa¬ 
mente  compatible  con  las  autotools  instaladas,  por  lo  que  haría  falta 
re-generarlo  desde  cero. 
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Opinamos  que  se  deberían  distribuir  ambos  tipos  de  ficheros,  tanto 
los  originales  configure  .  ac  y  Makef  ile  .  am  como  sus  derivados 
hasta  un  conjunto  directamente  ejecutable  en  una  plataforma  prefe¬ 
rida,  especificando  claramente  cuál  es  esta  plataforma  (por  ejemplo, 
una  distribución  y  versión  determinada),  aunque  tal  vez  también  se¬ 
ría  interesante  incluir  un  listado  de  los  ficheros  originales  antes  de 
ejecutar  las  autotools,  o  incluso  un  script  que  permitiese  quitar  los  fi¬ 
cheros  generados  para  satisfacer  todas  las  posibles  necesidades. 

4.3.5.  Chanaeloas  v  documentación 

Un  aspecto  que  no  se  debe  descuidar  es  la  correcta  documentación 
de  los  proyectos  de  software.  Aún  cuando  esto  es  importante  incluso 
en  un  entorno  de  programación  "artístico"  donde  una  sola  persona 
desarrolle  y  mantenga  todo  el  código,  este  aspecto  se  vuelve  crucial 
en  los  desarrollos  GNU,  donde  el  mismo  código  normalmente  será 
analizado  y  mejorado  por  diferentes  desarrolladores  con  poco  o  in¬ 
cluso  ningún  contacto  previo  entre  sí,  sea  por  motivos  geográficos, 
temporales  u  otros. 


Debido  a  la  relevancia  de  la  documentación,  y  a  la  facilidad  con  la 
que  puede  olvidarse  incluir,  es  por  lo  que  automake  comprueba  su 
presencia  antes  de  dar  por  válido  el  conjunto  de  ficheros. 


El  fichero  de  documentación  más  relevante,  de  referencia  tanto  para 
usuarios  noveles,  avanzados  como  para  administradores,  es  el 
ChangeLog.  De  ahí  que  el  formato  tenga  una  estructura  bastante 
definida  y  comunmente  aceptada. 


El  fichero  ChangeLog  consta  de  una  serie  de  "entradas",  en  orden  de 
fechas  o  versiones  decrecientes  (lo  más  nuevo  primero),  cada  una 
de  las  cuales  comienza  con  una  línea  definiendo  la  fecha,  persona 
y  e-mail  en  que  se  realizan  los  cambios,  seguida  de  una  lista  de 
cambios  separados  por  líneas  en  blanco  y  normalmente  con  el 
margen  ligeramente  desplazado  y  precedidos  de  asterisco  (*). 

Cada  cambio  suele  incluir  una  referencia  del  módulo,  archivo  o  funcio¬ 
nalidad  cambiada  o  actualizada,  y  una  descripción  corta  del  cambio  en 
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sí,  opcionalmente  seguida  de  un  código  identificativo  (por  ejemplo  si  se 
trata  de  una  corrección  de  un  bug,  el  número  del  bug). 

Los  cambios  que  se  realicen  sobre  elementos  relacionados  pueden 
incluirse  dentro  de  un  solo  cambio  o  detallarse  en  líneas  distintas,  sin 
embargo  en  el  segundo  caso  pueden  no  ir  separadas  por  una  línea 
en  blanco. 

Por  ahora  veamos  unos  ejemplos. 


Para  empezar,  un  trozo  del  fichero  .  /kdb/ChangeLog  del  kernel: 

2004-08-14  Keith  Owens  <kaos@sgi . com> 

*  kdb  v4 . 4-2 . 6 . 8-common-l . 

2004-08-12  Keith  Owens  <kaos@sgi . com> 

*  kdb  v4 . 4-2 . 6 . 8-rc4-common-l . 

2004-08-05  Keith  Owens  <kaos@sgi . com> 

*  Mark  kdb_initcall  as  _ attribute_used _  for  newer  gcc. 

*  kdb  v4 . 4-2 . 6 . 8-rc3-common-2 . 

O  del  fichero  ChangeLog  de  gcc: 

2004-07-01  Release  Manager 

*  GCC  3.4.1  released. 

2004-06-28  Neil  Booth  <neil@duron . akihabara . co . uk> 

PR  preprocessor/16192 
PR  preprocessor/15913 
PR  preprocessor/15572 

*  cppexp.c  (_cpp_parse_expr) :  Handle  remaining  cases  where  an 
expression  is  missing. 

*  cppinit.c  (post_options) :  Traditional  cpp  doesn't  do  //  comments . 

*  doc/cpp . texi :  Don ' t  document  what  we  do  for  ill-formed  expressions. 

*  doc/cppopts . texi :  Clarify  processing  of  command-line  defines. 

2004-06-28  Richard  Sandiford  <rsandifo@redhat . com> 

PR  target/16176 

*  conf ig/mips/mips . c  (mips_expand_unaligned_load) :  Use  a  temporary 
register  for  the  destination  of  the  lwl  or  ldl . 


Lectura  recomendada 


Una  descripción  más  deta¬ 
llada  puede  encontrarse  en 
la  dirección  siguiente: 
http://www.gnu.org/prep/ 
standards/html_node/ 
Change-Logs.html# 
Change-Logs 


Otros  registros  de  cambios  siguen  un  formato  lógico  parecido, 
aunque  no  directamente  compatible,  como  por  ejemplo  el  fichero 
CHANGES  de  Apache  2.0.52: 
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Software  libre 


Changes  with  Apache  2.0.52 

*)  Use  HTML  2.0  <hr>  for  error  pages .  PR  30732  [André  Malo] 

*)  Fix  the  global  mutex  crash  when  the  global  mutex  is  never  allocatec 
due  to  disabled/empty  caches.  [Jess  Hollé  cjessh  ptc.com>] 

*)  Fix  a  segfault  in  the  LDAP  cache  when  it  is  configured  switched 
off.  [Jess  Hollé  cjessh  ptc.com>] 

*)  SECURITY :  CAN-2004-0811  (cve.mitre.org) 

Fix  merging  of  the  Satisfy  directive,  which  was  applied  to 

the  surrounding  context  and  could  allow  access  despite  configured 

authentication .  PR  31315.  [Rici  Lake  Crici  ricilake . net>] 


4.3.6.  Creación  de  confiqure.in 

Una  duda  que  puede  plantearse  al  definir  el  fichero  configure .  in 
es  la  de  qué  poner  dentro.  En  concreto,  qué  chequeos  deberían  de 
realizarse  para  que  el  programa  funcionase  correctamente,  sin  exce¬ 
derse  en  chequeos  que  puedan  fallar  en  el  sistema  destino  sin  que  in¬ 
fluyesen  en  la  compilación,  o  simplemente  en  qué  orden  realizarlos. 

4.3.7.  ¿Qué  siaifica  portabilidad? 

Un  programa  idealmente  portable  es  aquél  que  un  usuario  pueda  ha¬ 
cer  funcionar  sin  mayor  esfuerzo  en  cualquier  plataforma  y  sistema 
posible.  De  forma  ideal  esto  supondría  que  sólo  tuviese  que  ejecutar 
un  comando  para  tener  el  programa  instalado  y  funcionando. 

Este  sería  un  caso  ideal,  que  sería  trivial  de  resolver  si  todos  los  sis¬ 
temas  y  plataformas  fuesen  idénticos  entre  sí.  Sin  embargo,  en  la 
realidad  esto  nunca  se  cumple,  e  incluso  no  sería  deseable  que  se 
cumpliese.  Los  sistemas  difieren  entre  sí,  las  plataformas  difieren,  in¬ 
cluso  dentro  de  una  misma  plataforma  y  sistema  difieren  los  progra¬ 
mas,  utilidades  y  las  versiones  instaladas  de  cada  uno. 

Por  lo  tanto,  para  ser  portable,  un  programa  debe  ser  capaz  de 
adaptarse  al  entorno  donde  vaya  a  ejecutarse. 

Con  el  fin  de  que  estas  adaptaciones  no  se  hagan  imposibles  debi¬ 
do  a  la  existencia  de  infinitas  variables,  hay  establecida  una  serie 
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de  estándares,  convenciones  y  costumbres  que  facilitarán  al  pro¬ 
grama  tanto  la  identificación  del  entorno  donde  va  a  ejecutarse 
como  la  adaptación  al  mismo. 

En  el  caso  concreto  de  las  autotools  se  suele  hablar  de  sistemas  "tipo 
Unix",  tales  como  Linux,  BSD,  SunOS,  Solaris,  etc.  además  de  las  dis¬ 
tintas  variantes  de  cada  uno.  Incluso  se  puede  pensar  en  compatibilidad 
con  sistemas  Windows,  MacOS  u  otros. 


4.3.8.  Introducción  al  sh  portable 

La  herramienta  más  importante  para  la  instalación  de  un  programa 
es  el  programa  de  línea  de  comando  en  sí.  Este  será  el  encargado 
de  servir  de  base  al  resto  de  comandos  ejecutados  durante  el  proce¬ 
so  de  instalación. 


Para  evitar  problemas  de  compatibilidad  entre  distintas  implementacio- 
nes  de  sh,  especialmente  aquellas  carentes  de  algunas  funcionalidades 
extendidas,  las  autotools  intentan  generar  un  fichero  ./configure 
con  el  conjunto  de  funcionalidades  de  sh  más  compatible  posible.  Esto 
puede  llevar  a  que  el  código  resultante  no  sea  fácilmente  legible  para 
alguien  acostumbrado  a  las  implementaciones  más  difundidas. 

Por  otro  lado,  la  programación  bajo  sh  se  sirve  en  gran  medida  de 
otros  programas  "de  apoyo",  que  también  tienen  distintas  imple- 
mentaciones  y  no  siempre  se  comportan  de  una  manera  exactamen¬ 
te  igual  a  la  esperada. 


Debido  a  esto  los  programas  GNU  suelen  incluir  una  sección  en  su 
documentación  (man)  detalando  las  opciones  que  soportan  compa¬ 
tibles  con  POSIX,  el  estándar  de  compatibilidad  entre  sistemas  ope¬ 
rativos.  Siguiendo  estas  opciones  soportadas  y  evitando  las  demás, 
es  bastante  probable  que  un  script  sea  altamente  portable. 


4.3.9.  Chequeos  necesarios 


Lectura  recomendada 


El  estándar  POSIX  se  puede 
consultar  en  la  dirección  si¬ 
guiente: 

http://www.unix.org/ 
version3/ieee_std .  htm  I 

De  especial  interés  será  la 
sección  "Shell  Command 
Language". 


Gracias  a  autoscan  hemos  podido  ver  una  configuración  básica  com¬ 
patible  con  el  proyecto.  Sin  embargo,  muchas  veces  no  es  suficiente 
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con  esta  configuración  básica  y  cada  proyecto  puede  tener  sus  pecu¬ 
liaridades  que  deban  ser  tomadas  en  cuenta  a  la  hora  de  realizar  los 
chequeos. 

Hay  que  tener  en  mente  que  el  fichero  configure. am  es  interpretado 
como  fichero  de  script  con  "macros  intercaladas"  que  serán  expan¬ 
didas  por  autoconf  (usando  m4).  Por  lo  tanto  se  puede  incluir  en  él 
cualquier  trozo  de  código  de  script  shell  para  realizar  comprobacio¬ 
nes  adicionales,  o  condicionar  la  realización  de  comprobaciones  a 
distintos  aspectos. 

La  secuencia  principal  recomendada  suele  ser  la  siguiente: 

1)  Inicialización.  Aquí  se  incluye  el  código  de  inicio  de  las  distin¬ 
tas  comprobaciones,  como  puede  ser  AC_INIT  o 
AM_INI T_AUTOMAKE. 

2)  Configuración.  Se  establecen  distintas  opciones  como 

AC_CONFIG_SRCDIR o  AC_CONFIG_HEADER. 

3)  Programas.  Aquí  se  comprueba  la  presencia  de  programas  nece¬ 
sarios  para  la  compilación  o  la  ejecución  del  mismo  proceso  de  con¬ 
figuración.  En  caso  de  estar  presentes  varios  posibles,  también  se 
suele  elegir  el  más  adecuado. 

4)  Librerías.  Se  comprueba  la  existencia  de  las  librerías  necesarias 
para  compilar  el  programa.  Esto  es  recomendable  hacerlo  antes  de 
los  siguientes  pasos  dado  que  en  algunos  se  comprueba  la  presencia 
de  funcionalidades  intentando  compilar  programas  de  ejemplo  que 
las  utilicen. 

5)  Encabezados.  Esto  se  refiere  a  los  encabezados  de  librerías  y  mó¬ 
dulos  instalados  en  el  sistema  para  los  que  también  estén  instalados 
los  encabezados  de  compilación,  necesarios  para  compilar  el  pro¬ 
grama. 

6)  Typedefs  y  estructuras.  Se  realizan  comprobaciones  de  existencia 
de  typedefs  y  estructuras  en  los  encabezados  detectados  en  el  paso 
anterior. 

7)  Funciones.  Esta  comprobación  es  la  realmente  importante,  que 
detectará  la  presencia  de  funciones  utilizadas  en  el  programa  en 
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función  de  los  encabezados  y  librerías  presentes,  comprobando  la 
posibilidad  de  usarlas  aplicando  los  typedefs  y  estructuras  encontrados. 

8)  Salida.  Este  es  el  paso  final  que  creará  los  ficheros  de  salida  en 
función  de  las  opciones  detectadas. 


4.4.  Introducción  a  GNU  Automake 


Automake  es  la  utilidad  encargada  de  crear  los  ficheros  Makefile  .  in 
en  base  a  una  definición  simple  de  lo  que  hace  falta  hacer  y  cumpliendo 
con  los  estándares  de  creación  de  ficheros  Makefile  de  GNU. 

Por  un  lado  esto  facilita  la  creación  de  los  Makefile  al  no  tener  que 
especificar  en  cada  uno  todos  los  pasos  que  se  deben  dar,  simplifi¬ 
cando  su  creación. 

Por  otro,  al  crear  los  ficheros  Makefile  con  un  formato  uniforme, 
será  más  fácil  procesarlos  con  utilidades  estándar  compatibles  con 
dicho  formato. 

Al  mismo  tiempo,  dada  la  gran  popularidad  de  estos  ficheros 
Makefile,  necesarios  para  la  compilación  de  prácticamente  todos 
los  programas,  una  gran  cantidad  de  usuarios  es  capaz  de  aportar 
información  sobre  cualquier  tipo  de  incompatibilidad,  error,  u  op¬ 
timización  que  se  deba  corregir  o  incorporar  a  automake. 


4.4.1.  Principios  generales  de  automake 

Como  ya  se  ha  mencionado,  automake  se  encarga  de  convertir  Make¬ 
file.  am  en  Makefile.  in  que  posteriormente  será  usado  por  ./ 
configure  como  una  plantilla  para  los  ficheros  Makefile  finales. 

Por  lo  tanto,  los  ficheros  Makefile.  am  se  pueden  entender  como 
ficheros  Makefile  normales  con  macros. 


Lectura  recomendada 


Una  referencia  completa  de 
las  opciones  de  configura¬ 
ción  se  puede  encontrar  en 
la  dirección  siguiente: 
http://www.gnu.org/ 
software/autoconf/auto- 
conf.html  (Online  Manual) 


Lectura  recomendada 


Una  referencia  completa 
sobre  automake  se  puede 
encontrar  en  la  dirección  si¬ 
guiente: 

http://directory.fsf.org/ 
GNU/automake.html 
(User  manual) 


Un  aspecto  diferente  respecto  a  los  Makefile  son  los  comentarios  in¬ 
ternos  de  automake,  que  serán  descartados  al  crear  el  Makefile  .  in, 
y  que  empezarán  con  '##'  en  vez  de 
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##  Este  es  un  fichero  Makefile.am  de  ejemplo  (esta  linea  no  aparecerá) 


Aparte  de  esto,  automake  soporta  líneas  condicionales  y  expansiones  de 
inelude  que  se  procesarán  para  generar  el  fichero  Makef  ile  .  in. 

Todas  las  instrucciones  y  posibles  macros  no  interpretadas  directa¬ 
mente  por  automake  son  pasadas  tal  cual  a  Makef  ile  .  in. 

4.4.2.  Introducción  a  las  primarias 

Las  variables  "primarias"  se  utilizan  indirectamente  para  derivar  de 
ellas  nombres  de  objetos  a  partir  de  ellas. 

Por  ejemplo  PROGRAMS  es  una  primaria,  y  bin_PROGRAMS  es  un 
nombre  derivado  de  ella: 

bin_PROGRAMS  =  nul 

En  este  caso  se  usa  el  prefijo  especial  bin  que  indicaría  el  destino 
del  programa  en  "bindir".  Algunos  de  los  destinos  posibles  son  los 
siguientes: 

•  bindir:  donde  deben  ir  los  archivos  binarios 

•  sbindir:  para  los  archivos  binarios  de  sistemas 

•  libexeedir:  programas  y  demonios  ejecutables  por  otros  pro¬ 
gramas 

•  pkglibdir:  librerías  no  compartidas  en  el  sistema 

•  noinst:  archivos  que  no  se  instalarán 

•  check:  sólo  serán  compilados  con  "make  check"  para  compro¬ 
baciones 

•  man:  páginas  de  manual 
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Para  indicar  el  código  fuente  que  formará  el  destino  "nul"  especifi¬ 
cado  antes,  usaremos  la  primaria  SOURCES: 


nul  SOURCES  =  nul . c 


Aparte  de  estas  primarias  principales,  también  están  disponibles: 

•  HEADERS:  permite  listar  los  encabezados  .  h  de  los  ficheros. 

•  SCRIPTS:  lista  los  Scripts  ejecutables.  Serán  copiados  sin  inter¬ 
pretar,  aunque  con  atributos  de  ejecución. 

•  DATA:  ficheros  que  serán  copiados  directamente.  Suelen  ser  con¬ 
tenidos  fijos  utilizados  por  el  programa,  como  fuentes  de  datos  o 
gráficos. 

•  MANS:  se  refiere  a  las  páginas  de  manual.  Suelen  usarse  como 
man_MANS  o  manl_MANS,  man2_MANS,  etc.  para  permitir  la  ins¬ 
talación  en  secciones  concretas  del  manual. 


4.4.3.  Programas  v  librerías 

Como  ya  se  ha  mencionado,  los  programas  se  indican  bajo  la  pri¬ 
maria  PROGRAMS. 


En  el  caso  de  las  librerías,  se  aplica  la  primaria  LIBRARIES: 


lib_LIBRARIES  =  libtest.a 

libtest  a  SOURCES  =  ltest.c  ltest.h 


Para  libertas  libtool  (ver  más  adelante)  tenemos  la  primaria  LTLI BRARI ES : 


lib_LIBRARIES  =  libtest. la 

libtest  la  SOURCES  =  ltest.c  ltest.h 


Como  se  puede  apreciar,  el  punto  de  "libtest .  a"  se  convierte  en 
un  guión  bajo  para  dar  lugar  al  prefijo  de  objeto  "libtest_a". 
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4.4.4.  Múltiples  directorios 

Un  proyecto  mínimamente  grande  y  bien  organizado,  suele  estar  di¬ 
vidido  en  diferentes  subdirectorios. 

Para  procesar  estructuras  de  directorio  respecto  al  actual,  automake 
acepta  la  opción  SUBDIRS: 

SUBDIRS  =  src  libsrc  man 

La  única  restricción  es  que  los  directorios  deben  ser  descendientes  del 
actual,  por  lo  que  si  se  desea  procesar  también  un  segundo  nivel 
como  por  ejemplo  src/main/,  se  debería  incluir  este  subdirectorio 
main  en  el  fichero  Makef  ile  .  am  de  src: 


src/Makef ile .  am 

SUBDIRS  =  .  main 


4.4.5.  Cómo  probarlo 

Una  de  las  características  de  automake  y  de  los  Makefile  genera¬ 
dos,  es  la  capacidad  de  realizar  tests  de  funcionamiento  del  código 
compilado. 

Bajo  el  destino  check  de  Makefile,  invocado  con  make  check,  se  eje¬ 
cutarán  una  serie  de  programas  especificados  en  la  variable  TESTS 
de  Makefile .  am.  En  esta  variable  se  pueden  especificar  tanto  ob¬ 
jetos  fuente  como  objetos  derivados. 

Cada  programa  testeado  debe  devolver  un  valor  cero  para  indicar  test 
pasado,  o  distinto  de  cero  para  indicar  test  fallido.  Los  tests  que  no  ten¬ 
gan  validez  en  la  plataforma  o  entorno  de  compilación,  pueden  de¬ 
volver  el  valor  77  para  no  ser  tenidos  en  cuenta  en  el  cómputo  final. 

Igualmente,  es  posible  especificar  una  lista  de  tests  que  se  espera  que 
fallen  con  la  variable  XFAIL_TESTS,  que  serán  considerados  como 
válidos  en  el  caso  inverso  que  los  no  especificados.  Estos  tests  tam¬ 
bién  deben  incluirse  en  la  variable  TESTS  para  ser  ejecutados. 
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Para  especificar  un  destino  común  a  todos  los  programas  de  test,  se 
puede  usar  el  destino  check  con  la  primaria  PROGRAMS: 

check_PROGRAMS  =  testl  test2 
testl_SOURCES  =  testl. c 
test2  SOURCES  =  test2.c 


Así  mismo,  se  pueden  ejecutar  los  tests  de  DejaGnu  con: 


AUTOMAKEJDPTIONS  =  de j agnu 


4.5.  La  librería  GNU  Líbtool 


Libtool  es  una  herramienta  que  permite  abstraer  el  proceso  de  com¬ 
pilación  de  librerías  del  formato  concreto  que  estas  vayan  a  tomar 
forma  en  la  plataforma  donde  sean  compiladas,  incluyendo  el  con¬ 
trol  de  versiones  y  las  dependencias  entre  librerías. 


Esto  es  especialmente  importante  en  el  caso  de  librerías  que  puedan 
ser  compartidas  en  el  sistema  destino,  aunque  también  es  un  añadido 
cómodo  para  el  desarrollo  normal  de  librerías  independientemente  de 
la  plataforma. 


Para  conseguirlo,  las  librerías  y  los  ejecutables  se  compilan  en  un  for¬ 
mato  ejecutable  modificado,  nombrándose  con  la  extensión  .  la  en 
vez  de  .  a. 


Además,  libtool  ha  sido  pensada  de  forma  que  esté  integrada  con 
las  utilidades  autoconf  y  automake,  aunque  no  sea  obligatorio  que 
estas  estén  instaladas  para  poder  hacer  uso  de  libtool. 


4.5.1.  Código  independiente 


Lectura  recomendada 


Se  puede  encontrar  más  in¬ 
formación  sobre  Libtool  en 
la  dirección  siguiente: 

http://www.gnu.org/ 
softwa  re/libtool/ 
manual.html 


Para  una  librería  interna  de  un  programa  no  es  necesario  que  su  có¬ 
digo  sea  independiente  de  posición  (Position  Independent  Code  =  PIC). 
Sin  embargo,  al  crear  librerías  compartidas  entre  distintos  programas, 
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hace  falta  que  la  dirección  en  la  que  se  carga  la  librería  sea  alterable, 
de  forma  que  las  direcciones  internas  deberán  ser  relativas  al  punto  de 
inicio,  o  alteradas  en  el  momento  de  cargar  la  librería. 

Para  crear  código  independiente,  hace  falta  pasar  una  serie  de  op¬ 
ciones  al  compilador.  Esta  tarea  puede  ocultarse  usando  libtool,  que 
se  encargará  de  todo  el  proceso  de  compilado. 


Normalmente,  el  código  independente  se  generará  como  objetos 
.  lo,  a  diferencia  del  código  normal  .  o. 


4.5.2.  Librerías  compartidas 

Por  defecto,  libtool  siempre  creará  librerías  compartidas,  salvo  en 
las  plataformas  donde  esto  no  sea  posible  o  que  se  le  requiera  explí¬ 
citamente  construir  librerías  estáticas. 


Veamos  esto  con  unos  ejemplos. 


Para  ello  vamos  a  crear  una  librería  básica  de  ejemplo: 


suma . c 

int  suma  (int  a,  int  b)  { 
return  a+b; 

} 


Una  compilación  normal  sin  utilizar  libtool  consistiría  en: 


$  gcc  -c  suma . c 
$  ls 

suma . c  suma . o 
$  ar  cru  libsuma.a  suma. o 
$  ranlib  libsuma.a 
$  ls 

libsuma.a  suma.c  suma. o 


En  este  caso  la  librería  creada  es  estática. 
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Para  crear  una  librería  compartida,  podríamos  recurrir  a  libtool: 


$  libtool  --mode=compile  gcc  -c  suma . c 
mkdir  .libs 

gcc  -c  suma . c  -fPIC  -DPIC  -o  . libs/suma . o 
gcc  -c  suma . c  -o  suma. o  >/dev/null  2>&1 
$  libtool  --mode=link  gcc  -o  libsuma.la  suma. lo  -rpath  /usr/local/lib/ 
rm  -fr  . libs/libsuma . a  . libs/libsuma . la 

gcc  -shared  .libs/suma. o  -Wl, -soname  -Wl, libsuma . so . 0  -o  . libs/libsuma . so . 0 . 0 . 0 
(cd  .libs  &&  rm  -f  libsuma. so. 0  &&  ln  -s  libsuma . so . 0 . 0 . 0  libsuma . so . 0 ) 

(cd  .libs  &&  rm  -f  libsuma. so  &&  ln  -s  libsuma . so . 0 . 0 . 0  libsuma. so) 
ar  cru  . libs/libsuma . a  .libs/suma. o 
ranlib  . libs/libsuma . a 
creating  libsuma.la 

(cd  .libs  &&  rm  -f  libsuma.la  &&  ln  -s  ../libsuma.la  libsuma.la) 

$  ls 

libsuma.la  suma.c  suma. lo  suma. o 


Con  la  opcion  -rpath  especificamos  la  dirección  donde  estará  ins¬ 
talada  la  librería. 


4.5.3.  Librerías  estáticas 

Para  aprovechar  la  capacidad  de  interfaz  estándar  de  creación  de  li¬ 
brerías,  libtool  también  permite  crear  librerías  estáticas  sin  tener 
que  llamar  directamente  al  compilador,  especificando  la  opción  - 
static  en  la  fase  de  enlazado: 

$  libtool  --mode=link  gcc  -static  -o  libsuma.la  suma. lo 

rm  -fr  . libs/libsuma . a  . libs/libsuma . la 

ar  cru  . libs/libsuma . a  suma. o 

ranlib  . libs/libsuma . a 

creating  libsuma.la 

(cd  .libs  &&  rm  -f  libsuma.la  &&  ln  -s  ../libsuma.la  libsuma.la) 


De  esta  forma  se  creará  una  librería  que  contendrá  todos  los  objetos 
referenciados  por  la  misma. 


Para  probar  el  correcto  funcionamiento  de  esta  librería,  deberemos 
enlazarla  ¡unto  a  un  ejecutable. 
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Por  ejemplo,  en  este  caso  usaremos  este  ejecutable  mínimo: 

main . c 

#include  <stdio.h> 

int  suma  (int  a,  int  b) ; 

int  main  (int  argc,  char  *argv[])  { 
printf  ( " % i " ,  suma  (1,  2)  ); 
exit  (0)  ; 

} 


Ahora  compilemos  este  programa  incluyendo  la  librería  anterior: 


$  libtool  --mode=link  gcc  -o  suma  main.c  libsuma.la 

gcc  -o  .libs/suma  main.c  . / . libs/libsuma . so  -Wl,--rpath  -Wl, /usr/local/lib, 
creating  suma 
$  ./suma 
3 


Vemos  que  el  programa  funciona  perfectamente,  llamando  la  fun¬ 
ción  de  la  librería. 


4.5.4.  Enlazar  una  librería.  Dependencias 
entre  librerías 


Es  bastante  común  enlazar  una  librería  con  otras  ya  existentes  para 
añadir  o  agrupar  funcionalidad  en  una  sola,  o  para  maximizar  las 
capacidades  de  portabilidad  de  un  programa  al  no  depender  de  la 
existencia  o  no  de  librerías  en  el  sistema  destino. 


Libtool  usará  el  sistema  soportado  en  destino  para  la  inter-depen- 
dencia  de  librerías,  de  manera  transparente  al  usuario. 


En  caso  de  no  encontrar  un  medio  nativo  para  resolverlas,  libtool 
ofrece  una  emulación  propia. 
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4.5.5.  Usar  librerías  de  conveniencia 


Las  librerías  de  conveniencia  son  librerías  parcialmente  enlazadas  que 
pueden  usarse  como  agrupaciones  intermedias  de  objetos  aunque  no 
sean  ni  ejecutables  ni  librerías  cargables  en  sí.  Estas  librerías  se  defi¬ 
nen  simplemente  sin  especificar  ni  -static  ni  -rpath  en  el  momento  de 
llamar  libtool  como  --mode=compile,  y  son  usadas  sólo  para  ser 
enlazadas  dentro  de  otras  librerías  o  ficheros  ejecutables. 


4.5.6.  Instalación  de  librerías  v  ejecutables 

La  instalación  de  librerías  por  medio  de  libtool  en  realidad  no 
supone  mayor  problema. 

$  libtool  --mode=install  cp  libsuma.la  /usr/local/lib/libsuma . la 
cp  libsuma.la  /usr/local/lib/libsuma . la 
cp  . libs/libsuma. a  /usr/local/lib/libsuma . a 
ranlib  /usr/local/lib/libsuma . a 


Para  finalizar  la  instalación  usaremos  --mode=f inish: 


libtool  --mode=finish  /usr/local/lib 
PATH="$PATH : /sbin"  ldconfig  -n  /usr/local/lib 


Librarles  have  been  installed  in: 

/usr/local/lib 

If  you  ever  happen  to  want  to  link  against  installed  librarles 
in  a  given  directory,  LIBDIR,  you  must  either  use  libtool,  and 
specify  the  full  pathname  of  the  library,  or  use  the  '-LLIBDIR* 
flag  during  linking  and  do  at  least  one  of  the  following: 

-  add  LIBDIR  to  the  ' LD_LIBRARY_PATH '  environment  variable 
during  execution 

-  add  LIBDIR  to  the  ' LD_RUN_PATH '  environment  variable 
during  linking 

-  use  the  '-Wl, --rpath  -Wl, LIBDIR'  linker  flag 

-  have  your  system  administrator  add  LIBDIR  to  ' /etc/ld . so . conf ' 

See  any  operating  system  documentation  about  shared  librarles  for 
more  information,  such  as  the  ld(l)  and  Id. so (8)  manual  pages . 


Con  esto  ya  podremos  usar  nuestra  librería  compartida. 
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4.5.7.  Desinstalación 


La  desinstalación  podemos  realizarla  por  medio  de  --mode=uninstall 
con  el  comando  rm: 


$  libtool  --mode=uninstall  rm  -f  /usr/local/lib/libsuma . la 
rm  -f  /usr/local/lib/libsuma . la  /usr/local/lib/libsuma . a 

rm  -f  /usr/local/lib/libsuma . la  /usr/local/lib/libsuma . so . 0 . 0 . 0  /usr/local/lib/libsuma . so . 0  /usr/ 
local /I ib /libsuma . so  /usr/local/lib/libsuma . a 


De  esta  forma  se  asegura  que  la  librería  quedará  desinstalada  inde¬ 
pendientemente  de  la  plataforma,  incluidos  cualquier  enlace  a  la 
misma  que  pudiese  haber  sido  necesario  crear  en  la  instalación. 


4.5.8.  GNU  Libtool.  configure. in  y  Makefile.am 

Para  utilizar  libtool  con  autoconf  y  automake  sólo  hace  falta  definir 

su  uso  en  configure  .  ac. 

La  macro  que  nos  ofrece  autoconf  para  ello  es  la 
AC_PROG_LIBTOOL.  Al  mismo  tiempo,  no  harán  falta  comproba¬ 
ciones  adicionales  relacionadas  con  la  compilación  de  librerías, 
pues  de  todo  ello  se  encargará  libtool: 

AC_PROG_LIBTOOL 

Tras  esto,  sólo  tendremos  que  ejecutar  autoconf  y  automake  como 
de  costumbre. 


4.5.9.  Integración  con  configure. in,  opciones  extra 
y  macros  para  Libtool 

La  compilación  con  libtool  añade  una  serie  de  opciones  nuevas  a 
.  / configure,  entre  ellas: 

--enable-shared 

--disable-shared:  permiten  activar  o  desacrivar  la  compilación 
de  librerías  compartidas. 
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--enable-static 


--disable-static:  igualmente  para  librerías  estáticas, 
--with-pic:  fuerza  a  construir  librerías  con  código  independiente  (PIC) . 
Estas  opciones  tienen  sus  correspondientes  opciones  de  configure .  ac: 


AC  DI SABLE  SHARED 


para  desactivar  las  compilación  de  librerías  compartidas,  y 


AC  DI SABLE  STATIC 


para  desactivar  las  compilación  de  estáticas. 


4.5.10.  Integración  con  Makefile.am,  creación 

de  librerías  con  Automake  v  linkado  contra 

librerías  Libtool 


Automake  soporta  la  compilación  y  enlazado  de  librerías  por  medio 
del  destino  lib  y  la  primaria  LIBRARIES: 


lib_LIBRARIES  =  libsuma.a 
libsuma  a  SOURCES  =  suma . c 


La  construcción  de  librerías  con  el  uso  de  libtools,  utiliza  la  primaria 

LTLIBRARIES: 


lib_LTLIBRARIES  =  libsuma. la 
libsuma  la  SOURCES  =  suma.c 


El  enlazado  contra  librerías  libtool  se  obtiene  por  medio  de  la 
primaria  LDADD: 


bin_PROGRAMS  =  suma 
suma_SOURCES  =  main.c 
suma  LDADD  =  libsuma. c 
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4.5.1 1 .  Utilización  de  libtoolize 

La  herramienta  que  nos  ayudará  a  configurar  nuestro  proyecto  para 
hacer  uso  de  libtool,  como  añadir  y  comprobar  que  está  presente 
el  soporte  para  libtool,  es  libtoolize. 

El  proceso  completo  de  creación  de  nuestro  proyecto,  haciendo  uso 
de  libtool,  puede  ser  el  siguiente. 


configure . ac 

AC_INIT (suma,  0.1) 
AM_INIT_AUTOMAKE (suma,  0.1) 
AC_CONFIG_SRCDIR ( [suma.c] ) 

#  Checks  for  programs . 
AC_PROG_CC 
AC_PROG_L IBTOOL 

AC_CONFIG_FILES ( [Makefile] ) 
AC_OUTPUT 

Makefile . am 

bin_PROGRAMS  =  suma 
suma_SOURCES  =  main.c 
suma_LDADD  =  libsuma.la 

lib_LTLIBRARIES  =  libsuma.la 
libsuma  la  SOURCES  =  suma.c 


Una  vez  hechas  las  modificaciones  correspondientes  para  añadir  so¬ 
porte  de  libtool  y  establecer  los  ficheros  fuente  y  destino  a  usar  en 
configure,  ac  y  Makefile.am,  comprobemos  que  el  proyecto 
compila  correctamente: 


$  ls 

AUTHORS  ChangeLog  configure. ac  main.c  Makefile.am  NEWS  nul . c  README  suma 
$  libtoolize 

You  should  add  the  contents  of  ' /usr/share/aclocal/libtool .m4 '  to  ' aclocal .m4 ' . 

$  aclocal 

$  automake  --add-missing 

automake:  configure . ac :  installing  ' . /install-sh ' 
automake:  configure . ac :  installing  ' . /mkinstalldirs ’ 
automake:  configure . ac :  installing  './missing' 
automake:  Makefile.am:  installing  './INSTALL' 
automake:  Makefile.am:  installing  './COPYING' 


176 


$  autoconf 
$  ./configure 

[.  .  .] 

$  make  all 


creating  suma 
$  ls  *suma* 

libsuma.la  suma*  suma.c  suma. lo  suma. o 
$  ./suma 
3 

Como  podemos  observar,  se  han  creado  todos  los  elementos  correc¬ 
tamente  y  compilado  el  programa  final. 


Nota 


En  algunos  casos  no  hará 
falta  ejecutar  libtoolize 
directamente,  sino  que  será 
llamado  por  automake  - 
add-missing  (en  este 
ejemplo  habría  funcionado 
correctamente). 


4.5.12.  Versjongdo  de  librerías 

La  creación  de  librerías,  especialmente  las  compartidas  a  ser  instaladas 
en  el  sistema,  requiere  una  serie  de  consideraciones  adicionales  re¬ 
lativas  a  la  versión  de  las  librerías  distribuidas. 

En  el  momento  de  la  carga  de  librerías,  será  elegida  aquella  que 
cumpla  una  serie  de  condiciones  relativas  a  la  compatibilidad  con  el 
programa  que  la  necesite,  definidas  por  medio  del  número  de  ver¬ 
sión.  Este  número  de  versión,  aunque  puede  ser  distinto  en  cada  pla¬ 
taforma,  es  abstraído  por  libtool  a  un  formato  unificado  visto  en 
función  de  las  interfaces  exportadas  por  la  librería.  De  esta  forma  se 
permite  que  un  programa  con  interfaz  compatible  pueda  cargar  una 
librería  posterior  a  su  distribución,  que  puede  tener  corregidos  fallos  o 
añadida  funcionalidad  sin  perder  compatibilidad  hacia  atrás. 

Como  interfaz  entenderemos,  a  efectos  de  versionado,  los  tipos  y  nom¬ 
bres  de  variables  globales,  las  funciones  globales  (tipos  de  argumentos, 
valor  de  retorno,  nombres  de  funciones),  entrada/salida/error  estándar 
y  formatos  de  ficheros,  sockets,  tuberías,  y  otras  formas  de  comunica¬ 
ción  entre  procesos  y  sus  formatos. 

Bajo  libtool  las  librerías  se  entiende  que  exportan  "conjuntos  de  in¬ 
terfaces"  numerados  secuencialmente.  Al  intentar  cargarlas,  será 
elegida  aquella  librería  que  soporte  todos  los  números  de  interfaz  re¬ 
queridos  por  el  programa. 
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Los  números  de  interfaz  se  establecen  por  medio  de  la  opción  — ver- 
sion-info,  especificada  en  el  modo  de  libtool  --mode=link  o 
en  la  primaria  LDFLAGS  de  Makefile .  am,  con  el  formato  de: 


actual  :  revisión  :  antigüedad 


•  actual:  establece  el  número  de  la  interfaz  más  moderna  sopor¬ 
tada. 

•  revisión:  permite  distribuir  librerías  actualizadas  con  la  misma 
interfaz. 

•  antigüedad:  número  de  interfaces  anteriores  soportadas. 

El  total  de  interfaces  soportadas  estará  definido  por  el  intervalo: 

desde  actual  -  antigüedad  hasta  actual 


Así,  una  librería  definida  como  1:1:0  soportará  sólo  la  interfaz  nú¬ 
mero  1 ,  revisión  1 . 


Mientras,  la  librería  definida  2:1:1  soportará  tanto  la  interfaz  1  como 
la  2,  de  la  cual  soportará  la  revisión  1 ,  por  lo  que  podrá  ser  cargada 
en  lugar  de  la  1:1 :0. 


La  librería  con  versión  2:2:1,  igualmente  podrá  ser  cargada  por  los 
programas  que  necesiten  la  1  o  la  2: 1 : 1 . 


Sin  embargo  una  librería  2:3:0,  habrá  roto  la  compatibilidad  con  los 
programas  para  la  1 ,  y  sólo  será  compatible  con  los  que  acepten  la  2, 
aunque  no  con  un  programa  que  necesite  la  2:4. 


4.6.  Conclusiones 


La  preparación  de  un  entorno  de  desarrollo  GNU  es  muy  distinta  en 
la  forma,  las  utilidades  y  aplicaciones  a  instalar  y  el  fondo  a  los  entor¬ 
nos  propietarios  y  visuales  usados  en  sistemas  operativos  Windows. 
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Estas  diferencias  se  ponen  de  manifiesto  en  el  uso  de  herramientas 
poco  comunes  en  otros  sistemas,  no  solo  funcional  sino  visualmente. 

En  este  capítulo  se  han  definido  las  tareas,  sentado  las  bases  y  reco¬ 
nocido  el  software  necesario  para  configurar  nuestro  entorno  de  de¬ 
sarrollo  GNU,  de  forma  que  podamos  avanzar  en  el  uso  de  IDEs  de 
desarrollo  y  herramientas  visuales  en  capítulos  consecutivos. 
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5.  Control  de  versiones 


5.1 .  Introducción 


Los  sistemas  de  control  de  versiones  funcionan  como  la  columna  ver¬ 
tebral  permitiendo  a  grupos  de  personas  trabajar  de  forma  conjunta 
en  el  desarrollo  de  proyectos,  frecuentemente  a  través  de  Internet.  Son 
sistemas  que  señalan  las  diferentes  versiones  para  identificarlas  poste¬ 
riormente,  facilitan  el  trabajo  en  paralelo  de  grupos  de  usuarios,  indi¬ 
can  la  evolución  de  los  diferentes  módulos  del  proyecto,  y  disponen  de 
un  control  detallado  de  los  cambios  que  se  han  realizado;  funciones 
que  son  indispensables  durante  la  vida  del  proyecto.  Estos  sistemas  no 
sólo  tienen  aplicación  en  el  desarrollo  del  software,  sino  que  además 
son  ampliamente  utilizados  en  la  creación  de  documentación,  sitios 
web  y  en  general  cualquier  proyecto  colaborativo  que  requiera  traba¬ 
jar  con  equipos  de  personas  de  forma  concurrente. 

En  el  mundo  del  software  propietario,  los  sistemas  de  control  de  ver¬ 
siones  han  sido  tradicionalmente  usados  para  gestionar  equipos  de 
desarrollo  en  entornos  corporativos  cerrados.  Con  la  explosión  de  In¬ 
ternet  y  el  avance  del  software  libre,  se  diseñaron  sistemas  abiertos 
que  permitieran  trabajar  simultáneamente  a  miles  de  personas  dis¬ 
tribuidas  en  diferentes  regiones  del  mundo  en  un  mismo  proyecto  a 
través  de  Internet. 

CVS  ( concurrent  versions  system )  es  el  programa  más  utilizado  en  el 
mundo  del  software  libre  para  el  control  de  versiones  de  software. 
Basado  en  el  modelo  cliente-servidor,  existen  versiones  del  progra¬ 
ma  para  multitud  de  plataformas.  Su  solidez  y  su  probada  eficacia, 
tanto  en  grupos  pequeños  de  usuarios  como  en  grandes,  le  han  con¬ 
vertido  en  la  herramienta  que  utilizan  proyectos  de  software  libre  de 
éxito  reconocido  como  Mozilla,  OpenOffice.org,  KDE  o  GNOME, 
por  mencionar  sólo  algunos.  Veremos  también  Subversión,  un  nuevo 
sistema  de  control  de  versiones  con  prestaciones  superiores  a  CVS. 
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Durante  este  capítulo  aprenderemos  cómo  utilizar  CVS  y  Subversión 
para  facilitar  el  trabajo  entre  un  grupo  de  usuarios  que  trabajan  en 
un  mismo  proyecto  y  veremos  la  utilidad  de  disponer  de  un  sistema 
de  control  de  versiones. 


5.2.  Objetivos 

Los  materiales  didácticos  asociados  a  este  capítulo  permitirán  obte¬ 
ner  los  siguientes  conocimientos: 

•  Familiarizarse  con  la  parte  cliente  de  CVS  y  Subversión  para  po¬ 
der  seguir  la  evolución  de  un  proyecto  de  software  donde  partici¬ 
pen  diversos  desarrolladores. 

•  Cómo  enviar  cambios  y  correcciones  a  través  de  CVS  o  por  correo 
electrónico  usando  los  comandos  diff  y  patch. 

•  Cómo  instalar  y  administrar  un  servidor  CVS  propio  donde  publi¬ 
car  los  proyectos  y  compartirlos  con  otros  usuarios. 

•  El  funcionamiento  de  los  sistemas  de  versionado  de  archivos,  por 
etiqueta,  fechas  o  ramas. 


5.3.  Sistemas  de  control  de  versiones 


Las  funciones  principales  de  los  sistemas  de  control  de  versiones  son 
proporcionar  un  histórico  de  los  cambios  de  los  archivos  de  un  proyec¬ 
to  y  permitir  recuperar  una  determinada  versión  del  archivo  en  cual¬ 
quier  momento.  Imaginemos  que  tenemos  la  versión  1 .00  de  un 
archivo  de  instrucciones  de  instalación  de  un  programa.  A  este  archivo 
de  texto  le  añadimos  varios  párrafos  que  indican  los  pasos  detallados 
que  hay  que  seguir  para  instalar  nuestro  programa  en  versiones  de 
UNIX  BSD  y  esta  nueva  versión  con  instrucciones  para  BSD  se  convierte 
en  la  versión  1.01  del  documento.  A  medida  que  el  proyecto  sigue 
avanzando,  este  archivo  continúa  evolucionando.  Con  un  sistema  de 
control  de  versiones,  en  cualquier  momento  podemos  obtener  la 
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versión  1.00  o  1.01  sin  necesidad  de  mantener  copias  separadas 
de  los  archivos. 

Los  sistemas  de  control  de  versiones  se  basan  en  mantener  todos  los 
archivos  del  proyecto  en  un  lugar  centralizado,  normalmente  un  único 
servidor.  Aunque  también  hay  sistemas  distribuidos,  donde  los  desa¬ 
rrolladores  se  conectan  y  descargan  una  copia  en  local  del  proyecto. 
Con  ella,  envían  periódicamente  los  cambios  que  realizan  al  servidor 
y  van  actualizando  su  directorio  de  trabajo  que  otros  usuarios  a  su  vez 
han  ido  modificando. 

Los  sistemas  de  control  de  versiones  de  código  están  integrados  en 
el  proceso  de  desarrollo  de  software  de  muchas  empresas.  Cualquier 
empresa  que  tenga  más  de  un  programador  trabajando  en  un  mis¬ 
mo  proyecto  acostumbra  a  tener  un  sistema  de  este  tipo,  y  a  medida 
que  crece  el  número  de  personas  que  se  involucran  en  un  proyecto, 
más  indispensable  se  hace  un  sistema  de  control  de  versiones. 


5.3.1.  Algunos  términos  comunes 

Los  sistemas  de  control  de  versiones  tienen  una  terminología  muy  es¬ 
pecífica  para  referirse  a  conceptos  singulares  de  este  tipo  de  sistemas. 

A  continuación,  veremos  los  conceptos  y  términos  más  habituales 
del  paquete  de  software  CVS  y  que  son  extensibles  a  la  mayoría  de 
sistemas: 

Acceso  anónimo.  Tipo  de  acceso  a  un  servidor  con  el  cual  tenemos 
derecho  a  ver  y  copiar  los  archivos  del  repositorio,  pero  no  a  modi¬ 
ficarlos. 

Repositorio.  Lugar  centralizado  donde  se  almacena  la  copia  de  to¬ 
dos  los  archivos  del  proyecto  que  compartimos  con  todos  los  usua¬ 
rios  y  que  habitualmente  reside  en  un  único  servidor. 

Directorio  de  trabajo.  Versión  del  proyecto  que  proviene  del  reposito¬ 
rio  y  que  un  usuario  tiene  en  su  disco  duro  local  y  sobre  la  cual  trabaja. 

Commif.  Acción  con  la  que  enviamos  los  cambios  que  hemos  realiza¬ 
do  en  nuestro  directorio  de  trabajo  al  repositorio  central  del  servidor. 
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También  se  utiliza  para  añadir  de  forma  definitiva  nuevos  archivos  al 
repositorio. 

Rama.  A  partir  de  un  punto  concreto  se  crea  una  bifurcación  del  pro¬ 
yecto  que  puede  evolucionar  por  separado. 

Etiqueta.  Nombre  simbólico  que  asignamos  a  un  archivo  o  grupo  de 
archivos  del  proyecto  para  indicar  que  la  versión  tiene  un  significado 
especial  en  nuestro  proceso  de  desarrollo.  Con  este  nombre  nos  po¬ 
dremos  referir  a  los  archivos  más  adelante. 

Tarball.  Copia  completa  de  un  proyecto  en  un  punto  determinado 
realizada  con  el  comando  tar  de  Unix.  Es  muy  frecuente  realizar  una 
copia  de  todos  los  archivos  de  un  proyecto  en  este  formato  porque 
es  mucho  más  rápido  de  descargar  por  Internet  que  mediante  CVS  o 
Subversión. 


5.3.2.  Características  de  los  sistemas  de  control 
de  versiones 


Todos  los  sistemas  de  control  de  versiones  modernas  permiten  un 
conjunto  de  funciones  que  se  consideran  indispensables  para  cono¬ 
cer  exactamente  el  estado  de  un  proyecto.  A  continuación  enumera¬ 
mos  las  funciones  principales: 

•  Control  de  usuarios.  Establecer  qué  usuarios  tienen  acceso  a  los 
archivos  del  proyecto  y  qué  tipo  de  acceso  tienen  asignado. 

•  Mantener  un  control  detallado  de  cada  archivo.  Disponer  de  un 
control  de  cambios  que  se  han  efectuado  en  el  archivo,  en  qué  fecha, 
con  qué  motivo,  quién  los  realizó  y  mantener  las  diferentes  versiones. 

•  Mezclar  dos  versiones  diferentes  del  mismo  archivo.  En  caso  de 
que  dos  usuarios  modifiquen  un  archivo  (sistemas  de  no  blo¬ 
queo  de  archivos)  proporcionar  herramientas  para  gestionar 
este  tipo  de  conflictos. 

•  Bifurcación  de  proyectos.  A  partir  de  un  punto  concreto,  crear 
dos  ramas  del  proyecto  que  pueden  evolucionar  por  separado.  Es 
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habitual  utilizar  esta  técnica  cuando  hemos  liberado  una  versión 
de  un  producto  y  necesitaremos  que  siga  evolucionando. 


5.3.3.  Principales  sistemas  de  control  de  versiones 

Existe  una  buena  oferta  de  sistemas  de  control  de  versiones  disponi¬ 
bles  como  software  propietario  y  libre,  aunque  durante  este  capítulo 
nos  centraremos  en  los  sistemas  CVS  y  Subversión  que  son  solucio¬ 
nes  libres.  Mencionaremos  brevemente  los  principales  sistemas  de 
control  de  versiones  existentes  en  el  mercado: 


•  CVS  (concurrent  versions  system) 


Es  el  sistema  más  utilizado  en  el  mundo  del  software  libre  para  el 
control  de  versiones.  Basado  en  el  modelo  cliente-servidor,  el  propio 
sistema  es  software  libre  y  existen  versiones  del  software  para  multi¬ 
tud  de  plataformas.  Su  solidez  y  su  probada  eficacia,  tanto  en  grupos 
pequeños  de  usuarios  como  en  grandes,  le  han  convertido  en  la  he¬ 
rramienta  que  utilizan  proyectos  de  software  libre  como  Mozilla, 
OpenOffice.org,  KDE  o  GNOME,  por  mencionar  solamente  algunos. 


Nota 


http://www.cvshome.org 


•  RCS  ( revisión  control  system ) 


El  sistema  CVS  en  realidad  está  basado  en  otro  anterior  RCS  ( revisión 
control  system )  que  fue  desarrollado  por  Walter  Tichy  en  la  Universi¬ 
dad  de  Purdue  a  principios  de  1980.  El  sistema  RCS  es  extremada¬ 
mente  simple  y  fácil  de  instalar,  pero  no  puede  cubrir  las  necesidades 
de  proyectos  o  equipos  medianos.  Entre  las  limitaciones  más  nota¬ 
bles  de  RCS,  destaca  que  sólo  puede  trabajar  en  un  único  directorio 
cuando  la  mayoría  de  proyectos  tienen  múltiples  directorios.  RCS  uti¬ 
liza  un  sistema  de  bloqueo  de  archivos  que  impide  a  varios  desarro¬ 
lladores  trabajar  sobre  el  mismo  archivo. 


Nota 


http://www.gnu.org/ 
softwa  re/rcs/ res .  ht  m  I 


•  BitKeeper 


BitKeeper  es  un  producto  propietario  desarrollado  por  la  empresa 
BitMover.  Es  probablemente  el  producto  más  sofisticado  de  su  cate¬ 
goría.  Entre  las  características  que  lo  diferencian  del  resto  de  produc¬ 
tos,  destacan  la  posibilidad  de  trabajar  con  repositorios  distribuidos 


Nota 


http://www.bitkeeper.com 
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y  un  sistema  muy  avanzando  para  integrar  diferentes  versiones  de  un 
mismo  archivo. 


•  Microsoft  Visual  Source  Safe 


Nota 


http://msdn.microsoft.com/ 

ssafe 


Es  uno  de  los  productos  más  utilizados  para  desarrollo  de  aplicacio¬ 
nes  Windows.  Principalmente  porque  se  integra  en  el  entorno  de  tra¬ 
bajo  de  Visual  Studio  y  con  el  resto  de  herramientas  de  desarrollo  de 
Microsoft.  Tiene  funciones  de  comparación  visual  de  archivos  real¬ 
mente  avanzadas,  en  su  modo  básico  de  funcionamiento  utiliza  blo¬ 
queo  de  archivos. 


5.3.4.  Sistemas  de  compartición 

Un  punto  crítico  para  los  sistemas  de  control  es  la  gestión  de  un  archivo 
que  es  utilizado  por  varios  usuarios  al  mismo  tiempo.  El  mecanismo  que 
utilicen  para  resolver  este  tipo  de  situación  tendrá  implicaciones  en  la 
forma  como  los  usuarios  pueden  trabajar  simultáneamente  con  el  archi¬ 
vo  y  como  se  gestionan  los  cambios  que  se  realizan.  Existen  dos  sistemas 
de  compartición: 

•  Por  bloqueo  de  archivo 

Es  el  sistema  más  primitivo  y  el  que  utilizan  RCS  y  las  versiones  anti¬ 
guas  de  Visual  Source  Safe  de  Microsoft.  Se  trata  de  bloquear  el  ar¬ 
chivo  cuando  un  usuario  está  haciendo  cambios  de  tal  modo  que  los 
otros  usuarios  no  pueden  realizar  modificaciones  hasta  que  no  fina¬ 
lice  el  usuario. 

Es  habitual  que  un  usuario  empiece  a  trabajar  en  un  archivo  y  nece¬ 
site  varias  horas  para  añadir  el  nuevo  código  o  modificar  el  existente, 
por  esta  razón,  estos  sistemas  no  son  muy  adecuados,  ya  que  un  mis¬ 
mo  usuario  puede  bloquear  un  archivo  durante  un  periodo  largo  de 
tiempo  durante  el  cual  ningún  otro  usuario  puede  realizar  cambios. 

•  Por  gestión  de  cambios 

Este  sistema  permite  que  cualquier  usuario  o  grupos  de  usuarios  mo¬ 
difiquen  al  mismo  tiempo  un  archivo.  Cuando  han  finalizado  los 
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cambios,  realizan  una  operación  commit,  que  comprueba  las  dife¬ 
rencias  entre  el  archivo  en  el  servidor  y  el  mejorado  por  el  desarro¬ 
llador  y  envía  los  cambios.  Éste  es  el  método  que  utiliza  CVS. 

El  método  es  una  mejora  substancial  sobre  el  sistema  de  bloqueo  de 
archivos,  ya  que  permite  a  más  de  un  usuario  trabajar  sobre  el  mis¬ 
mo  archivo,  pero  introduce  un  nuevo  problema,  la  gestión  de  con¬ 
flictos.  Imaginemos  que  tenemos  dos  personas  que  están  trabajando 
sobre  el  mismo  archivo  y  sobre  la  misma  zona  del  archivo,  cuando 
el  primer  usuario  envíe  sus  cambios,  éstos  se  guardarán  en  el  servi¬ 
dor,  y  poco  después,  cuando  el  segundo  usuario  envíe  los  suyos,  se 
encontrará  que  la  copia  que  tenía  en  local  ha  cambiado  y  que  los 
cambios  no  se  pueden  integrar  automáticamente.  Disponemos  de 
sistemas  sofisticados  para  gestionar  lo  mejor  posible  este  tipo  de  si¬ 
tuaciones,  incluyendo  herramientas  visuales.  CVS  utiliza  un  sistema 
rudimentario,  donde  básicamente  nosotros  mismos  habremos  de  re- 
implementar  los  cambios. 


5.4.  Primeros  pasos  con  CVS 


5.4.1.  Instalación  de  CVS 

A  través  del  sitio  web  www.cvshome.org,  se  pueden  obtener  las  di¬ 
ferentes  versiones  cliente  y  servidor  del  programa  CVS.  La  mayo¬ 
ría  de  distribuciones  GNU/Linux  incluyen  paquetes  preparados 
con  las  herramientas  CVS.  De  hecho,  en  la  mayoría  vienen  insta¬ 
lados  por  defecto. 

Si  somos  usuarios  de  Debian  y  no  tenemos  instalado  CVS,  su  insta¬ 
lación,  como  la  del  resto  de  software  de  esta  distribución,  es  muy 
sencilla: 

$  apt-get  install  cvs 

Para  usuarios  de  la  distribución  Red  Hat,  lo  mejor  es  recurrir  a  los 
CD-ROM  originales  y  realizar  la  instalación  desde  el  entorno  gráfico 
o  con  la  siguiente  orden  de  línea  de  comandos: 

$  rpm  -ivh  cvs 
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Durante  este  temario  nos  referiremos  exclusivamente  a  las  versiones 
GNU/Linux  de  las  herramientas  CVS.  Si  necesitamos  trabajar  en  Mi¬ 
crosoft  Windows  existen  al  menos  dos  clientes: 


•  Cygwin 


Cygwin  es  una  emulación  completa  de  un  entorno  tipo  Unix  para 
Windows.  Disponemos  de  la  mayoría  de  herramientas  que  existen  en 
GNU/Linux,  incluyendo  una  versión  adaptada  de  CVS.  De  hecho, 
éste  es  el  entorno  en  que  se  desarrollan  algunos  proyectos  libres, 
como  Abiword  en  su  versión  Windows. 


Nota 


http://www.cygwin.com/ 

http://www.abiword.com 


La  ventaja  de  Cygwin  es  que  estamos  trabajando  con  la  versión 
adaptada  de  la  herramienta  original  de  CVS  para  Unix  en  entorno 
Windows,  de  tal  manera  que  su  comportamiento  es  idéntico  a  la  ver¬ 
sión  GNU/Linux  descrita  en  este  módulo. 


•  WinCVS 


Nota 


http://www.wincvs.org 


WinCVS  es  un  programa  libre  con  entorno  gráfico  para  plataforma 
Windows  que  permite  trabajar  con  repositorios  CVS.  Es  altamente  in¬ 
tuitivo  y  no  necesita  conocer  los  comandos  CVS,  ya  que  desde  el  en¬ 
torno  gráfico  se  pueden  realizar  todas  las  operaciones  necesarias. 


5.4.2.  Obtener  un  directorio  de  trabajo  de  un  provecto 
va  existente 


Una  buena  forma  de  tener  un  primer  contacto  con  CVS  es  utilizar  un 
servidor  de  un  proyecto  de  software  libre  y  obtener  una  copia  de  los 
archivos  del  proyecto. 


Nota 


En  la  página 

http://mozilla.org/cvs.html 
hay  información  detallada 
sobre  cómo  acceder  a  este 
servidor  mediante  CVS. 


El  sitio  web  www.mozilla.org  alberga  el  proyecto  Mozilla.  Este  pro¬ 
yecto  tiene  como  objetivo  producir  las  tecnologías  necesarias  que 
permitan  construir  un  conjunto  de  herramientas  para  trabajar  en  In¬ 
ternet.  Los  componentes  principales  de  Mozilla  son  un  navegador 
web,  un  sistema  de  correo  electrónico  y  un  editor  de  páginas  web, 
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aunque  el  número  de  herramientas  que  se  van  introduciendo  crece 
constantemente. 

Primero  definiremos  la  variable  de  entorno  CVSROOT,  que  indica  el 
servidor,  protocolo  de  acceso,  y  usuario  que  utilizaremos  para  acce¬ 
der  al  repositorio  CVS.  En  el  caso  del  proyecto  Mozilla,  definiremos 
la  variable  de  entorno  con  el  siguiente  valor: 


$  CVSROOT= : pserver : anonymous @ cvs -mirror .mozilla . org : /cvsroot 
$  export  CVSROOT 

Si  prestamos  atención  a  la  línea,  observaremos  que  nuestro  nombre  de 
usuario  es  anonymous  y  ya  forma  parte  de  la  cadena  CVSROOT,  de  este 
modo  sólo  tenemos  que  introducir  la  contraseña  para  identificarnos  con 
acceso  anónimo.  También  es  posible  usar  el  parámetro  -d  del  comando 
CVS  para  especificar  el  camino  al  servidor  CVS. 

Ahora  podemos  teclear  el  siguiente  comando: 


$  cvs  login 


CVS  contesta: 


Logging  in  to  : pserver :anonymous@cvs-mirror. mozilla. org: 240 1/cvsroot 
CVS  password: 


Este  comando  es  el  que  nos  permite  autentificarnos  en  el  servidor. 
La  contraseña  del  usuario  anonymous  para  el  proyecto  Mozilla  es 
anonymous.  En  algunos  servidores  para  el  acceso  anónimo  la 
contraseña  es  simplemente  <retorno>,  es  decir,  sin  contraseña. 
En  cualquier  caso,  depende  de  cómo  haya  configurado  el  admi¬ 
nistrador  el  sistema  repositorio. 

A  continuación  podemos  utilizar  el  comando  checkout  para  obtener 
el  código  del  proyecto  Mozilla.  Este  comando  es  el  que  utilizamos  la 
primera  vez  que  descargamos  un  proyecto  de  un  repositorio,  y  admi¬ 
te  como  parámetro  el  nombre  del  módulo.  Para  el  proyecto  Mozilla 
teclearemos: 


$  cvs  checkout  mozilla 
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CVS  muestra  los  nombres  de  los  archivos  que  se  van  descargando: 


cvs  server:  Updating  mozilla 
U  mozilla/ . cvsignore 
U  mozilla/LEGAL 
U  mozilla/L ICENSE 
U  mozilla/Makef ile . in 
U  mozilla/README. txt 
U  mozilla/aclocal .m4 


El  nombre  de  los  módulos,  en  este  caso  Mozilla,  es  arbitrario  y  defi¬ 
nido  por  el  administrador  del  repositorio.  De  hecho,  los  nombres  de 
los  módulos  son  los  nombres  de  los  directorios  raíz  del  proyecto. 

Si  examinamos  la  estructura  de  directorios  creada,  observaremos 
que  existe  un  directorio  CVS  para  cada  subdirectorio  del  proyecto. 
Estos  directorios  contienen  tres  archivos: 

•  Entries.  Contiene  los  archivos  de  este  directorio  que  están  refleja¬ 
dos  en  el  repositorio. 

•  Repository.  Contiene  la  ruta  relativa  al  módulo  al  que  pertenece 
este  archivo. 

•  Root.  Contiene  la  ruta  principal  al  servidor  CVS. 

Bajo  ningún  concepto  deben  borrarse,  y  en  caso  de  editarse,  debe 
hacerse  con  extremo  cuidado. 


Nota 

Podemos  practicar  con  otros  proyectos  libres,  en¬ 
contraremos  instrucciones  detalladas  de  cómo  des¬ 
cargar  el  proyecto  GNOME  vía  CVS  en  el  sitio  web 
www.gnome.org. 


5.4.3.  Sincronizándose  con  el  repositorio 

Una  vez  disponemos  de  una  copia  en  local  de  los  archivos,  ya  tene¬ 
mos  una  copia  del  proyecto  con  la  que  podemos  empezar  a  trabajar 
localmente.  Sin  embargo,  a  medida  que  pasan  los  días,  otros  usuarios 
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van  efectuando  cambios  en  el  repositorio  del  proyecto  y  en  consecuen¬ 
cia  nuestro  directorio  de  trabajo  queda  desactualizado  debido  a  que 
estos  nuevos  cambios  no  se  han  aplicado.  Es  habitual  que  nos  sin¬ 
cronicemos  con  el  repositorio  regularmente  para  mantener  nuestro 
directorio  de  trabajo  lo  más  actualizado  posible  del  proyecto.  Esta 
operación  se  realiza  con  el  comando  update,  de  la  siguiente  manera: 


$  cvs  update  -d  -P 


El  comando  update  acepta  diversos  parámetros,  pero  los  parámetros 
-d  y  -P  son  muy  habituales,  el  primero  construye  los  directorios  nece¬ 
sarios  y  el  segundo  elimina  de  nuestro  directorio  de  trabajo  los  direc¬ 
torios  que  han  quedado  vacíos. 

El  comando  update,  cuando  informa  de  los  archivos  actualizados, 
añade  una  letra  al  principio  del  nombre  de  archivo.  Estas  letras  tie¬ 
nen  el  siguiente  significado: 

•  C,  indica  que  hay  un  conflicto  en  el  archivo.  Ha  habido  una  ac¬ 
tualización  en  el  repositorio  y  en  el  directorio  de  trabajo  y  debe 
solucionarse  manualmente  el  conflicto. 

•  U,  el  directorio  de  trabajo  que  teníamos  era  antiguo  y  se  ha  ac¬ 
tualizado  con  la  versión  más  reciente  del  repositorio. 

•  M,  el  directorio  de  trabajo  del  archivo  tiene  cambios  pero  se  ha 
conseguido  una  actualización  automática  con  la  versión  más  re¬ 
ciente  del  repositorio. 

•  A,  si  el  archivo  ha  sido  añadido  pero  aún  no  hemos  efectuado  el 
comando  commit. 

•  R,  si  el  archivo  ha  sido  borrado  pero  aún  no  hemos  efectuado  el 
comando  commit. 

Durante  este  proceso  de  sincronización,  sólo  los  archivos  que  han  sido 
modificados  son  actualizados.  Es  importante  entender  que  el  comando 
update  en  ningún  caso  envía  las  modificaciones  que  hayamos  realiza¬ 
do  en  nuestro  directorio  de  trabajo  de  los  archivos  al  repositorio  (subir 
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cambios  al  repositorio),  sino  que  simplemente  nos  actualiza  nuestro  di¬ 
rectorio  de  trabajo  con  los  cambios  del  repositorio  (bajar  los  cambios  y 
actualizar  el  directorio  de  trabajo). 

5.4.4.  Cambios  al  repositorio 

Durante  el  proceso  normal  de  trabajo  en  un  proyecto,  es  habitual  ir 
modificando  archivos  a  medida  que  vamos  introduciendo  mejoras. 
Una  vez  hemos  finalizado  los  cambios,  éstos  deben  enviarse  al  repo¬ 
sitorio  para  que  todos  los  usuarios  puedan  acceder  a  las  mejoras  que 
hemos  efectuado. 

Antes  de  enviar  los  cambios,  resulta  interesante  ver  exactamente  qué 
cambios  hemos  realizado.  Para  ello  tenemos  el  comando  diff  que  si¬ 
gue  la  siguiente  sintaxis: 


$cvs  diff  -u  nombre  archivo 


Este  comando  nos  muestra  las  diferencias  de  nuestro  directorio  de 
trabajo  respecto  al  repositorio,  de  esta  manera  podemos  ver  qué 
cambios  exactamente  hemos  ido  realizando.  Hasta  ahora  hemos  vis¬ 
to  cómo  determinar  las  diferencias.  Ahora  veremos  cómo  enviar  es¬ 
tas  diferencias  al  repositorio,  el  comando  commlt  es  el  encargado  de 
enviar  los  cambios. 

Por  ejemplo,  modifiquemos  el  archivo  'README.TXT'  del  proyecto 
Mozilla  que  hemos  descargado  previamente  y  que  se  encuentra  en 
el  directorio  principal.  A  continuación  introduzcamos: 


$cvs  commit 

Después  de  procesar  todos  los  archivos  del  proyecto  en  busca  de  ar¬ 
chivos  con  modificaciones,  mostrará  una  lista  de  los  cambios  reali¬ 
zados;  por  defecto  esta  lista  se  muestra  en  el  editor  vi. 
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Podemos  definir  la  variable  de  entorno  CVSEDITOR  para  cambiar  el 
editor  por  defecto  que  deseamos  usar.  Como  respuesta  al  comando 
commit  CVS  mostrará: 


CVS: 


CVS:  Enter  Log.  Lines  beginning  with  'CVS:'  are  removed  automatically 
CVS: 

CVS:  Committing  in  . 

CVS: 

CVS:  Modified  Files: 

CVS :  README . txt 

CVS: - 


Si  deseamos  continuar,  teclearemos:  !  q,  que  es  la  orden  del  editor 
vi  para  salir  sin  guardar  los  cambios  del  registro  que  se  nos  acaba 
de  mostrar.  A  continuación  nos  preguntará  si  deseamos  enviar  los 
cambios  al  servidor.  CVS  nos  responderá: 


cvs  [server  aborted] :  "commit"  requires  write  access  to  the  repository 


Que  es  normal  en  este  caso,  ya  que  como  usuario  anónimo  del  pro¬ 
yecto  Mozilla  no  tenemos  derecho  a  modificar  los  archivos.  El  co¬ 
mando  commit  tiene  el  parámetro  -m  (mensaje)  que  es  muy  utilizado 
para  indicar  comentarios,  y  en  algunos  proyectos  es  casi  de  uso  obli¬ 
gado.  Por  ejemplo: 


cvs  commit  -m  "Solventa  el  problema  con  el  script  de  instalación 


Los  cambios  de  los  archivos  modificados  serán  enviados  al  repositorio  y 
registrados  con  el  comentario  indicado.  Los  comentarios  resultan  funda¬ 
mentales  durante  el  proyecto  para  entender  por  qué  nosotros  u  otras 
personas  han  introducido  los  cambios  en  el  proyecto. 


5.4.5.  Publicando  cambios  con  diffv  oatch 

No  es  extraño  que  en  un  proyecto  del  que  no  somos  colaboradores 
habituales  encontremos  un  error  en  el  programa,  incluso  es  proba¬ 
ble  que  tengamos  la  solución  y  queramos  enviarla  a  los  responsables 
del  proyecto.  Como  es  lógico,  no  tendremos  acceso  de  escritura  al 
repositorio  de  CVS  del  proyecto,  de  forma  que  no  podremos  publicar 
la  solución  al  repositorio  directamente.  Sin  embargo,  sí  que  pode¬ 
mos  publicar  nuestra  solución  al  problema  en  una  lista  de  correo  o 
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enviarlo  por  correo  electrónico  al  responsable  del  proyecto.  Para  ésta 
y  otras  situaciones  existen  la  pareja  de  comandos  diff  y  paich. 

Imaginemos  que  hemos  modificado  un  archivo  para  corregir  un 
error.  Para  crear  un  archivo  con  las  diferencias  que  hemos  introdu¬ 
cido,  haremos: 


$diff  -c  nombre_primer_archivo  nombre_segundo_archivo  >  fix.patc 


Por  defecto,  el  programa  diff  envía  la  salida  a  pantalla,  por  esto  re¬ 
dirigiremos  la  salida  al  archivo  fix.patch.  Este  archivo  contendrá  los 
cambios. 

La  persona  que  reciba  el  archivo  fix.patch  podrá  recuperar  las  mo¬ 
dificaciones  que  hemos  realizado  utilizando  el  comando  patch,  de  la 
siguiente  forma: 


$patch  <  archivo_para_aplicar_parches  <  parche 


Como  hemos  podido  observar,  ésta  es  una  forma  muy  sencilla  y  efi¬ 
ciente  de  enviar  correcciones  a  otros  usuarios  y  es  una  práctica  muy 
común  en  proyectos  de  software  libre. 


5.5.  Creación  y  administración  de  repositorios 


La  creación  de  un  repositorio  es  una  tarea  relativamente  sencilla.  Pri¬ 
mero  debemos  escoger  en  qué  directorio  del  sistema  de  archivos  va¬ 
mos  a  ubicar  el  repositorio.  Un  buen  lugar  puede  ser  /var/lib/cvs.  Es 
importante  tener  acceso  de  escritura  al  directorio  para  que,  cuando 
ejecutemos  CVS,  pueda  crear  los  archivos  necesarios. 

Una  vez  tenemos  los  permisos,  creamos  el  directorio  donde  se  ubi¬ 
cará  el  repositorio: 


$mkdir  cvs 


Tendremos  el  directorio  /var/lib/cvs.  Como  veremos  más  adelante, 
CVS  utiliza  la  gestión  de  usuarios  y  permisos  del  sistema  operativo. 
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Los  comandos  CVS  son  ejecutados  con  el  identificador  del  usuario 
que  ejecuta  el  comando.  Es  muy  importante  asegurarnos  de  que  to¬ 
dos  los  usuarios  tendrán  acceso  al  repositorio.  Un  método  sencillo  es 
asignar  al  directorio  el  grupo  users  para  que  todos  los  usuarios  que 
pertenecen  a  este  grupo  puedan  acceder  al  repositorio: 


Schgrp  users  /var/lib/cvs 


Luego  debemos  asignar  a  este  grupo  todos  los  usuarios  que  desea¬ 
mos  que  tengan  acceso  al  repositorio. 


Ahora  ya  tenemos  todo  preparado  para  que  CVS  inicialice  el  reposi¬ 
torio  y  cree  los  archivos  necesarios  para  su  gestión: 

$  cvs  -d  /var/lib/cvs  init 


El  comando  init  creará  el  repositorio  en  el  directorio  central  e  inicia- 
lizará  los  archivos  necesarios.  El  parámetro  -d  es  necesario,  ya  que 
indica  el  directorio  donde  se  ubicará  el  repositorio.  El  comando  no 
retorna  ningún  resultado  pero  podremos  observar  cómo  ha  creado 
un  directorio  en  /var/lib/cvs/CVSROOT  que  contiene  todos  los  archi¬ 
vos  que  necesita  CVS  para  gestionar  el  repositorio. 


Para  poder  compartir  el  repositorio  con  otros  usuarios,  nos  interesa 
ejecutar  CVS  en  modo  servidor.  CVS  utiliza  el  puerto  TCP  2401 .  Para 
instalar  este  servicio,  seguiremos  los  siguientes  pasos: 


1 )  Editamos  el  archivo  de  configuración  de  CVS,  llamado  cvs.conf.  Este 
archivo  se  encuentra  en  el  directorio  /var/lib/cvs.  Hemos  de  añadir  la  si¬ 
guiente  línea  que  indicará  dónde  se  halla  el  repositorio: 


CVS_REP0S="/ var/lib/cvs" 

2)  Necesitamos  activar  el  servicio.  Para  ello  deberemos  crear  un  archivo 
llamado  cvspserver  en  el  directorio  /etc/xinetd.d.  Este  archivo  indica  la 
descripción  del  servicio. 
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Nota 


Es  importante  comprobar 
qué  CVS  se  encuentra  real¬ 
mente  instalado  en  /usr/ 
bin/cvs 


Service  cvspserver 
{ 

port  =  2401 
disable  =  no 
socket_type  =  stream 
protocol  =  tcp 
wait  =  no 
user  =  root 

server  =  /usr/local/bin/cvs 

serverargs  =  -f  --allow-roof  =  /var/lib/cvs  pserver 
} 


Una  vez  activado  el  demonio  y  creado  el  repositorio,  nos  pode¬ 
mos  conectar  como  hemos  hecho  hasta  ahora.  Algunas  distribu¬ 
ciones  como  Debian  usan  el  demonio  inetd  y  la  forma  de 
configuración  difiere  a  la  comentada. 

$  CVSROOT= : pserver : anonymous@NOMBRE_DE_NUESTROPC : /var/lib/cvs 
$  export  CVSROOT 
$  cvs  login 


En  la  línea  CVSROOT,  debemos  substituir  NOMBRE_DE_NUESTROPC 
por  el  nombre  de  nuestra  máquina  GNU/Linux. 

Para  identificarnos,  cualquier  nombre  de  usuario  -con  los  privilegios 
adecuados  y  con  su  correspondiente  contraseña-  que  tengamos  de¬ 
finido  en  el  sistema  donde  hemos  instalado  el  servicio  será  válido 
para  acceder  al  repositorio. 


5.5.1.  Tipos  de  conexión  al  repositorio 

Hemos  visto  la  conexión  al  repositorio  mediante  el  método  pserver. 
Este  sistema  es  muy  básico  y  se  basa  en  enviar  las  contraseñas  sin 
encriptar,  de  forma  muy  similar  a  como  lo  hacen  los  protocolos  aso¬ 
ciados  a  las  aplicaciones  Telnet  o  FTP.  Este  nivel  de  seguridad  no  es 
suficiente  para  proyectos  donde  garantizar  la  seguridad  del  reposi¬ 
torio  sea  un  factor  importante.  También  debemos  recordar  que  los 
usuarios  de  CVS  son  válidos  en  la  propia  máquina,  por  lo  que  un 
problema  de  seguridad  con  CVS  se  extiende  a  toda  la  máquina. 

CVS  proporciona  la  posibilidad  de  trabajar  con  métodos  externos  de 
autentificación  para  mejorar  la  seguridad.  El  sistema  más  extendido 
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es  SSH  ( secure  shell),  que  permite  conexiones  cifradas,  la  contraseña 
viaja  cifrada  por  la  red,  y  además  permite  asegurarnos  de  que  el 
huésped  al  que  nos  conectamos  es  el  correcto.  Los  repositorios  de 
SourceGear  por  ejemplo  sólo  aceptan  conexiones  con  un  método  se¬ 
guro,  en  concreto  SSH. 


Nota 


www.sourcegear.net 


Para  activar  la  conexión  mediante  SSH,  es  necesario  definir  la  varia¬ 
ble  de  entorno  CVS_SSH  de  la  siguiente  manera: 


$  CVS_SSH=ssh 
$  export  CVS_SSH 


El  método  de  conexión  como  hemos  visto  se  define  en  la  variable 
CVSROOT.  La  utilización  de  SSH  requiere  la  correcta  instalación  del 
software  OpenSSH. 


5.5.2.  Importando  provectos  va  existentes 

Una  vez  el  repositorio  está  inicializado,  podemos  crear  la  estructura 
de  directorios  y  un  proyecto  nuevo,  o  bien  importar  un  proyecto  ya 
existente.  En  cualquier  caso,  es  importante  que  decidamos  previa¬ 
mente  la  estructura  de  directorios  que  queremos  que  tenga  nuestro 
proyecto,  ya  que  mover  archivos  con  CVS  no  es  muy  cómodo. 

El  comando  import  de  CVS  nos  facilita  la  importación  de  proyectos 
ya  existentes  al  repositorio.  Con  import,  podemos  importar  un  archi¬ 
vo  o  conjunto  de  archivos  como  parte  de  un  proyecto.  Por  ejemplo, 
importemos  todo  el  directorio  /home/jordi 

$cvs  import  directorio  vendortag  releasetag 

En  nuestro  caso: 

$cvs  import  codigo  vendorta  releasetag 

Donde  CVS  responde: 

I  codigo/simul . c 
I  codigo/comun . c 
I  codigo/corto/etapas . c 

197 


Software  libre 


Dependiendo  del  número  y  nombre  de  archivos  que  contenga  el  di¬ 
rectorio. 

Los  parámetros  vendortag  y  releasetag  se  utilizan  para  el  control  de 
versiones,  en  nuestro  caso  utilizamos  dos  nombres  arbitrarios. 


5.5.3.  Añadiendo  archivos  o  directorios 

Para  añadir  archivos  en  un  repertorio  CVS,  disponemos  del  coman¬ 
do  add.  Este  comando  permite  tanto  añadir  un  archivo  o  grupo  de 
archivos,  como  añadir  un  directorio  completo.  Para  añadir  un  archi¬ 
vo  tecleamos: 


$  cvs  add  nombre  de  archivo 


CVS  responde: 


cvs  server:  scheduling  file  ' nombre_de_archivo '  for  addition 
cvs  server:  use  'cvs  commit'  to  add  this  file  permanently 


Los  archivos  no  se  añadirán  de  forma  definitiva  al  repositorio  hasta 
que  realicemos  una  orden  commit,  para  enviar  todos  los  cambios  al 
servidor,  es  decir,  hasta  que  ejecutemos: 


$  cvs  commit 


que  enviará  los  cambios  al  servidor  y  los  hará  efectivos. 


5.5.4.  Los  archivos  binarios 

La  mayoría  de  herramientas  relacionadas  con  CVS  que  hemos  visto 
funcionan  sobre  archivos  de  texto,  ya  que  de  hecho  es  para  lo  que 
CVS  fue  originalmente  diseñado.  Sin  embargo,  en  un  proyecto  cual¬ 
quiera  es  habitual  encontrar  archivos  que  no  son  propiamente  de 
texto,  a  los  que  llamamos  binarios.  Entre  los  archivos  binarios  más 
habituales,  tenemos  los  archivos  gráficos,  de  sonido,  o  versiones  de 
un  software  compiladas  que  mantenemos  en  el  CVS. 
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El  problema  principal  radica  en  que  CVS  utiliza  dos  características, 
la  expansión  de  palabras  clave  y  la  conversión  de  retornos  de  carro 
que,  aplicadas  a  archivos  binarios,  modificarán  su  contenido  hacién¬ 
dolos  inservibles. 


Si  añadimos  un  archivo  binario,  es  importante  desactivar  estas  fun¬ 
ciones  para  este  archivo.  Para  añadir  archivos  binarios,  debemos 
hacer: 


$cvs  add  -kb  nombre  de  archivo 


El  parámetro  -kb  desactiva  las  características  que  pueden  dañar  un 
archivo  binario.  Como  en  el  caso  de  los  archivos  de  textos,  los  cam¬ 
bios  no  se  enviarán  hasta  que  ejecutemos  el  comando  commlt. 


5.5.5.  Eliminando  archivos  v  directorios 

La  eliminación  de  archivos  del  repositorio  es  una  operación  que  de¬ 
bemos  efectuar  con  cuidado.  Para  poder  eliminar  un  archivo,  prime¬ 
ro  lo  debemos  eliminar  de  nuestro  directorio  de  trabajo,  es  decir,  de 
nuestro  disco,  y  después  del  repositorio.  La  secuencia  de  instruccio¬ 
nes  es  la  siguiente: 


$  rm  nombre_de_archivo 
$  cvs  remove  nombre  de  archivo 


Como  en  el  caso  de  añadir  archivos,  la  operación  no  se  completa 
hasta  que  ejecutamos  el  comando  CVS  commit. 


El  método  visto  hasta  ahora  sirve  para  eliminar  archivos,  pero  no 
para  eliminar  directorios.  De  hecho,  CVS  no  permite  eliminar  direc¬ 
torios  debido  a  cómo  organiza  internamente  los  repositorios.  Lo  úni¬ 
co  que  podemos  hacer  es  eliminar  todos  los  archivos  del  directorio, 
dejarlo  vacío,  y  utilizar  siempre  el  parámetro  -P  del  comando  update 
cuando  nos  sincronicemos  con  el  repositorio,  para  que  no  se  creen 
en  nuestro  directorio  de  trabajo  los  directorios  vacíos. 
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5.5.6.  Moviendo  archivos 


CVS  no  dispone  de  ningún  comando  específico  para  poder  mover 
archivos  de  un  lugar  a  otro  del  repositorio.  Sin  embargo,  podemos 
emular  esta  funcionalidad  combinando  varias  operaciones  de  CVS. 

Para  mover  un  archivo,  lo  copiaremos  de  su  lugar  de  origen  en  nues¬ 
tro  directorio  de  trabajo  al  lugar  de  destino,  es  decir,  el  lugar  donde 
queremos  que  resida  en  el  futuro.  Una  vez  realizada  esta  operación 
sobre  el  repositorio,  eliminaremos  el  archivo  del  lugar  de  origen  y 
añadiremos  el  nuevo  archivo. 

La  secuencia  de  comandos  es  la  siguiente: 


$mv  dirorigen/origen  dirdestino/destino 
$cvs  add  dirdestino/destino 
$cvs  remove  dirorigen/origen 


Los  cambios  no  se  harán  efectivos  hasta  que  se  ejecute  el  comando 
commit.  Es  importante  destacar  que  con  esta  operación  perderemos 
el  histórico  de  etiquetas  y  comentarios  realizados  en  el  repositorio,  ya 
que  efectivamente  estamos  incluyendo  un  archivo  nuevo. 


5.6.  Trabajando  con  versiones,  etiquetas  y  ramas 


5.6.1.  Etiquetas  v  revisiones 

El  desarrollo  de  un  proyecto  es  un  proceso  vivo  donde  constantemen¬ 
te  van  produciéndose  cambios  como  parte  del  proceso  continuo  de 
mejora.  En  algunos  puntos  del  proyecto  interesa  tener  la  capacidad 
de  poder  indicar  que  en  este  preciso  momento  los  archivos  que  hay 
en  el  repositorio  forman  una  determinada  versión.  Este  proceso  se 
llama  etiqueta.  Es  muy  utilizado  para  marcar  una  versión  exacta  que 
liberamos  para  después  podernos  referir  de  forma  sencilla. 

Podemos  establecer  una  etiqueta  en  el  repositorio  fácilmente: 


$  cvs  tag  VersionlOO 
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De  esta  forma  etiquetaremos  todos  los  archivos  del  proyecto  con  la 
etiqueta  "Versionl 00".  A  medida  que  el  proyecto  sigue  evolucionan¬ 
do,  puede  ser  necesario  recuperar  una  versión  que  habíamos  mar¬ 
cado  anteriormente.  Para  ello,  utilizaremos  el  comando  update  que 
ya  conocemos: 

$  cvs  update  -r  VersionlOO 


De  esta  manera  obtendremos  una  nueva  copia  del  proyecto  tal  como 
estaba  en  el  momento  de  marcarlo  como  "VersionlOO".  Sin  embar¬ 
go,  esto  representa  un  pequeño  inconveniente,  ya  que  el  directorio 
de  trabajo  retrocederá  completo  al  estado  en  que  se  encontraba 
cuando  efectuamos  la  etiqueta,  probablemente  hace  unos  meses. 
Acostumbra  a  ser  mucho  más  práctico  descargar  una  versión  deter¬ 
minada  en  un  directorio  aparte,  podemos  hacerlo  de  la  siguiente 
manera: 

$  cvs  checkout  -r  VersionlOO 


También  es  posible  realizar  las  mismas  operaciones  basadas  en  la 
fecha  del  archivo.  Resulta  más  intuitivo  trabajar  con  etiquetas,  ya  que 
son  nombres  que  pueden  tener  un  significado  y  son  más  fáciles  de 
asociar  que  las  fechas. 


5.6.2.  Creación  de  ramas 

La  creación  de  ramas  es  muy  útil  cuando  trabajamos  en  paralelo  con 
varias  versiones  del  proyecto.  Por  ejemplo,  si  vamos  a  liberar  una 
versión  1 .0  de  un  producto.  En  ese  momento,  creamos  dos  ramas  del 
proyecto,  una  donde  está  la  versión  1 .0  y  donde  podemos  seguir  co¬ 
rrigiendo  los  posibles  errores  que  aparezcan  y  más  adelante  crear 
una  versión  1 .01 .  Al  mismo  tiempo,  podemos  tener  otra  rama  en  pa¬ 
ralelo  donde  el  proyecto  ya  ha  evolucionado  a  la  versión  1 .1  y  aún 
se  encuentra  en  fase  de  desarrollo.  Las  ramas  permiten  trabajar  con 
varias  versiones  del  mismo  proyecto  de  forma  concurrente. 

Podemos  crear  una  rama  con  el  siguiente  comando: 


cvs  tag  -b  nombre_de_la_rama  archivo 
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A  partir  de  ese  momento  podemos  continuar  operando  con  la  rama 
principal  de  CVS  y  cuando  nos  queramos  referir  a  la  rama  anterior¬ 
mente  creada,  podremos  hacerlo  usando  el  nombre_de_la_rama  es¬ 
cogido. 


5.7.  Bonsai:  gestión  de  CVS  vía  web 


Nota 


En  http://www.mozilla.org/ 
bonsai.html  podéis  encontrar 
la  página  principal  del  pro¬ 
yecto  Bonsai,  con  su  código 
fuente  e  instrucciones  detalla¬ 
das  para  su  instalación. 


Bonsai  es  una  herramienta  que  fue  creada  en  el  entorno  del  proyecto  de 
software  libre  Mozilla.  Esta  herramienta  permite  la  gestión  vía  web  de  un 
repositorio  CVS.  Su  utilidad  radica  en  que  añade  una  interfaz  visual  y  es 
extremadamente  útil  para  hacer  seguimientos  de  proyectos  donde  hay 
cambios  constantes  en  el  repositorio. 

En  este  capítulo,  nos  limitaremos  a  ver  su  funcionalidad  desde  la 
perspectiva  del  usuario. 


Entre  las  características  que  ofrece  Bonsái,  destacan: 


•  Posibilidad  de  ver  los  últimos  cambios  en  el  repositorio,  quién  los 
ha  efectuado,  a  qué  hora,  el  comentario  del  cambio,  etc. 

•  Ver  qué  cambios  se  han  efectuado  por  un  usuario  determinado, 
en  una  rama  del  proyecto,  o  en  un  periodo  de  tiempo. 

•  Ver  un  determinado  archivo  con  anotaciones  de  quién  fue  la  últi¬ 
ma  persona  que  cambió  cada  línea  del  archivo. 

•  Comparación  visual  de  los  diferentes  cambios  que  se  han  produ¬ 
cido  en  el  repositorio. 


Bonsai  sólo  permite  hacer  seguimiento  del  proyecto,  no  permite  hacer 
cambios  en  el  mismo.  A  través  de  la  página  http://bonsai.mozilla.org/, 
podemos  efectuar  todas  las  operaciones  descritas  sobre  el  repositorio 
del  proyecto  libre  Mozilla. 


Tabla  de  comandos  de  CVS 

La  tabla  que  viene  a  continuación  contiene  una  descripción  de  los 
principales  comandos  de  CVS. 
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Tabla  1.  Descripción  de  los  principales  comandos  de  CVS 


Comando 

Descripción 

add 

Añade  un  nuevo  archivo  o  un  conjunto  de  archivos  de  un  directorio  al  repositorio. 

admin 

Interfaz  de  administración. 

an  nótate 

Muestra  el  archivo  indicando  el  número  de  revisión  de  cada  línea  del  archivo  y  qué 
usuario  fue  el  último  que  la  modificó. 

checkout 

Obtiene  una  copia  de  los  archivos  del  repositorio  y  crea  nuestro  directorio  de  trabajo. 

commit 

Acción  con  la  que  enviamos  los  cambios  que  hemos  realizado  en  nuestro  directorio 
de  trabajo  al  repositorio  central  del  servidor. 

diff 

Muestra  las  diferencias  de  un  archivo  o  grupo  de  archivos  entre  nuestro  directorio 
de  trabajo  al  repositorio  central  del  servidor. 

edit 

Edita  los  archivos  bajo  observación. 

editors 

Muestra  quién  está  editando  archivos  bajo  observación. 

export 

Exporta  archivos  de  CVS,  similar  a  checkout. 

history 

Muestra  el  histórico  de  acceso  de  usuarios  al  repositorio  CVS. 

import 

Importa  archivos  al  repositorio  CVS. 

init 

Crea  e  inicializa  un  nuevo  repositorio. 

log 

Muestra  el  historial  de  los  archivos. 

login 

Autentifica  el  usuario.  Con  este  comando  introducimos  la  contraseña  de  nuestro  usuario  y 
nos  valida  en  el  servidor. 

logout 

Desconecta  al  usuario. 

pserver 

Servidor  en  modo  contraseña. 

ran  nótate 

Muestra  el  archivo  indicando  quién  ha  modificado  cada  línea  del  archivo. 

rdiff 

Crea  un  parche  con  la  diferencia  entre  dos  versiones  de  un  archivo. 

release 

Indica  que  el  módulo  ya  no  está  en  uso. 

re  m  ove 

Elimina  un  objeto  del  repositorio. 

rlog 

Muestra  el  histórico  para  un  módulo  del  repositorio. 

rtag 

Añade  una  etiqueta. 

server 

Modo  servidor. 

status 

Muestra  la  información  de  estado  de  los  archivos. 

tag 

Añade  una  etiqueta  a  los  archivos  del  repositorio. 

unedit 

Deshacer  una  modificación  realizada  por  un  comando  de  edición. 

update 

Actualiza  el  directorio  local  de  trabajo  con  la  copia  en  el  servidor. 

versión 

Muestra  la  versión  actual  del  programa  CVS. 

watch 

Establece  los  archivos  bajo  observación. 

watchers 

Muestra  los  usuarios  que  están  observando  archivos. 
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5.7.1.  Subversión 


Subversión  es  un  software  libre  de  control  de  versiones  que  nació  en 

el  año  2001  con  el  objetivo  de  solventar  las  principales  carencias  de 

CVS.  Muchos  desarrolladores  ven  en  Subversión  el  sistema  de  control 

de  versiones  que  sustituirá  a  CVS. 

Entre  las  principales  mejoras  de  Subversión  respecto  a  CVS,  destacan: 

•  Posibilidad  de  mover  archivos.  Una  de  las  grandes  limitaciones  de 
CVS  ha  sido  la  carencia  de  un  comando  para  poder  mover  archi¬ 
vos  entre  diferentes  partes  del  repositorio.  Subversión  finalmente 
corrige  esta  carencia. 

•  Commits  atómicos.  La  posibilidad  de  enviar  un  conjunto  de  cam¬ 
bios  al  repositorio  en  bloque  evitando  los  problemas  que  suceden 
en  CVS  cuando  enviamos  una  gran  cantidad  de  cambios  al  repo¬ 
sitorio  que  son  todos  parte  de  un  mismo  trabajo,  pero  sólo  parte 
de  ellos  son  aceptados  por  CVS. 

•  Metadatos.  Subversión  permite  guardar  por  cada  archivo  o  direc¬ 
torio  un  conjunto  de  llaves  emparejadas  con  su  valor  que  nos  per¬ 
miten  almacenar  metadatos  y  luego  recuperarlos. 

•  Versionado  por  directorios.  CVS  sólo  ofrece  control  de  versiones 
por  archivo,  con  Subversión  podemos  tener  también  control  por 
directorio. 

•  Soporte  para  diferentes  transportes  de  red.  Subversión  ha  sido  dise¬ 
ñado  para  que  sea  muy  sencillo  añadir  nuevos  transportes  de  red, 
como  conexiones  seguras  mediante  SSH  o  mediante  WebDAV. 

•  La  comparación  de  archivos  se  realiza  con  un  algoritmo  binario 
que  es  mucho  más  efectivo. 


5.7.2.  Instalación  d©  Subversión 

A  través  del  sitio  web  http://subversion.tigris.org/  se  pueden  obtener 
las  diferentes  versiones  cliente  y  servidor  del  programa  Subversión, 
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así  como  su  código  fuente.  La  mayoría  de  distribuciones  GNU/Linux 
incluyen  paquetes  preparados  con  las  herramientas  Subversión.  Po¬ 
demos  descargar  de  este  sitio  web  la  versión  especifica  de  nuestra 
distribución  GNU/Linux  o  bien  descargar  el  código  fuente,  compilar¬ 
lo  e  instalarlo  nosotros  mismos  como  haríamos  con  cualquier  otro 
paquete  de  software. 

Subversión  instala  varias  herramientas,  pero  las  principales  son: 

•  svn.  El  cliente  de  Subversión.  Con  él  realizaremos  las  operaciones 
principales  como  obtener  una  copia  de  trabajo,  sincronizar  nues¬ 
tra  copia  con  el  servidor  o  enviar  los  cambios  realizados. 

•  svnadmin.  La  herramienta  de  creación  y  administración  de  repo¬ 
sitorios.  Esta  es  la  herramienta  principal  de  administración  de 
Subversión. 


•  svnserve.  Servidor  ligero  que  funciona  como  demonio,  usual¬ 
mente  en  el  puerto  3690,  que  permite  a  clientes  svn  conectarse 
mediante  conexiones  TCP/IP  a  través  de  los  protocolos  svn://  y 
svn  +  ssh://. 


•  svnlook.  Herramienta  de  administración  de  repositorios  que  nos 
permite  examinar  el  histórico  del  repositorio. 


Existen  también  algunos  clientes  gráficos  para  diferentes  plataformas: 


•  TortoiseSVN 


Es  un  cliente  gráfico  de  Subversión  para  Microsoft  Windows  imple- 
mentado  como  una  extensión  de  la  shell  de  Windows. 


•  Rapid  SVN 


Nota 


http://tortoisesvn.tigris.org/ 

download.html 


Rapid  SVN  es  un  cliente  SVN  multiplataforma  que  funciona  sobre 
GNU/Linux,  Mac  y  Windows  y  que  proporciona  un  entorno  sencillo 
para  trabajar  con  Subversión. 


Nota 


http://rapidsvn.tigris.org/ 
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5.7.3.  Obtener  un  directorio  de  trabajo  de  un  provecto 
va  existente 

Para  poder  trabajar  con  un  proyecto  que  utiliza  Subversión,  necesi¬ 
tamos  empezar  obteniendo  un  directorio  de  trabajo  de  los  archivos 
del  proyecto.  Al  igual  que  con  CVS,  usamos  el  comando  checkout 
para  este  propósito.  Podemos  hacerlo  de  la  siguiente  manera: 


$  svn  checkout  repositorio 


Nota 


http://www.mono- 

project.com 


Donde  repositorio  es  el  repositorio  y  módulo  del  que  obtendremos 
una  copia,  Subversión  utiliza  URI  para  especificar  las  rutas  de  los  re¬ 
positorios.  Esto  permite  utilizar  una  forma  estándar  para  describir  lo¬ 
calizaciones  a  las  cuales  podemos  acceder  bajo  diferentes  transportes, 
como  file:///  (archivo  local),  http://  (vía  web)  o  https://  (vía  web  con  co¬ 
nexión  segura). 


Por  ejemplo,  para  obtener  una  copia  del  repositorio  Subversión  del 
proyecto  Mono,  usaremos: 


$  svn  checkout  svn+ssh: //user@mono-cvs . ximian . com/source/trunk/mono 


Donde  svn+ssh  es  el  tipo  de  transporte,  user  el  usuario  que  utilizare¬ 
mos,  y  el  resto  la  ruta  a  la  máquina  en  la  red  que  contiene  el  repo¬ 
sitorio. 


5.7.4.  Creación  de  repositorios 

Una  vez  instalado  Subversión,  debemos  crear  un  repositorio  donde 
se  almacenarán  nuestros  archivos.  Para  ello,  primero  nos  situaremos 
en  el  directorio  donde  queremos  crear  el  repositorio  y  luego  usare¬ 
mos  la  herramienta  de  administración  svnadmin  para  crearlo  con  los 
siguientes  comandos: 
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$mkdir  repositorio 
$svnadmin  create  repositorio 


Nota 


Para  el  resto  de  los  ejemplos  asumimos  que  el  directorio 
repositorio  se  ha  creado  en  el  subdirectorio  /home/jordi/ 
subversión,  por  lo  que  el  directorio  completo  al  reposito¬ 
rio  es  /home/jordi/subversion/repositorio. 

El  segundo  comando  crea  todos  los  archivos  necesarios  para  el  con¬ 
trol  del  repositorio  en  el  directorio  llamado  repositorio,  que  es  donde 
reside  el  repositorio  que  acabamos  de  crear. 

A  continuación,  lo  más  usual  es  importar  a  nuestro  repositorio  un 
proyecto  que  ya  tengamos. 

El  comando  import  nos  facilita  esta  tarea.  Con  ¡mport,  podemos  im¬ 
portar  un  archivo  o  conjunto  de  archivos  como  parte  de  un  proyecto. 
Por  ejemplo,  importemos  todo  el  directorio  /home/jordi  en  el  repo¬ 
sitorio  que  hemos  creado.  Para  ellos  tecleamos: 


$svn  import  /home/jordi/  f ile : ///home/ jordi/subversion/repositorio 


El  comando  mostrará  todos  los  archivos  que  se  han  importado  al  re¬ 
positorio. 

Ahora,  debemos  especificar  los  usuarios  que  van  a  tener  permiso  de 
modificación  al  repositorio.  Para  hacer  esto,  la  forma  más  sencilla  es 
crear  un  grupo  de  usuarios  y  asignar  todos  los  usuarios  que  quera¬ 
mos  que  tengan  acceso  de  modificación  al  repositorio  bajo  ese  gru¬ 
po.  Por  ejemplo,  creamos  el  grupo  usuariossvn  tecleando: 


Sgroupadd  usuariossvn 


Y  a  continuación  cambiamos  el  directorio  del  repositorio  de  grupo: 


$chgrp  -R  usuariossvn  repositorio 


Con  este  comando,  el  directorio  repositorio  pasa  a  pertenecer  al  gru¬ 
po  de  usuarios  usuariossvn.  A  continuación,  podemos  editar  el  fiche¬ 
ro  /etc/groups  para  añadir  los  usuarios  que  queremos  que  tengan 
acceso  en  escritura  al  repositorio  al  grupo  usuariossvn. 
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Una  vez  creado  y  configurado  el  repositorio  y  sus  usuarios,  podemos 
obtener  un  directorio  de  trabajo  local  tecleando: 


svn  checkout  svn: //usuario@dirección/home/ jordi/subversion/repositorio 


Donde  el  usuario  representa  el  usuario  que  utilizamos  para  autenti¬ 
ficarnos  en  el  repositorio  y  dirección  la  dirección  de  la  máquina  don¬ 
de  nos  conectamos,  por  ejemplo,  una  dirección  IP.  Para  podernos 
conectar  es  importante  iniciar  el  servidor  Subversión  tecleando: 

svnverve  -d 

5.7.5.  Comandos  básicos  con  Subversión 

A  continuación  veremos  algunos  de  los  comandos  básicos  de  Sub¬ 
versión  que  necesitamos  en  un  proyecto.  Prácticamente  todos  los  co¬ 
mandos  de  Subversión  tienen  el  mismo  nombre  y  sintaxis  que  los 
comandos  correspondientes  en  CVS.  Esto  es  así  para  minimizar  la 
curva  de  aprendizaje  de  los  usuarios  que  migran  del  sistema  CVS  a 
Subversión.  No  entraremos  en  detalle  en  aquellos  comandos  que 
son  de  comportamiento  idéntico. 

Para  actualizar  nuestro  directorio  de  trabajo,  al  igual  que  con  CVS 
usaremos  el  comando  UP  (abreviación  de  update ): 


$svn  up 


Durante  este  proceso  de  sincronización  sólo  los  archivos  que  han  sido 
modificados  son  actualizados.  Este  comando  en  ningún  caso  envía  las 
modificaciones  que  hayamos  realizado  en  nuestro  directorio  de  traba¬ 
jo,  sino  que  simplemente  nos  actualiza  nuestro  directorio  de  trabajo 
con  los  cambios  del  repositorio. 

Para  enviar  los  cambios  que  hayamos  realizado  al  repositorio  usare¬ 
mos  el  comando  commit: 

$svs  commit 
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Este  comando  envía  los  cambios  de  los  archivos  modificados  y  los  regis¬ 
tra  con  el  comentario  indicado.  Los  comentarios  resultan  fundamentales 


durante  el  proyecto  para  entender  por  qué  nosotros  u  otras  personas 
han  introducido  los  cambios  en  el  proyecto. 

Para  ver  las  diferencias  de  nuestro  directorio  de  trabajo  con  el  repo¬ 
sitorio,  usaremos  el  comando  diff.  Tecleamos: 

$svn  diff 

Este  comando  mostrará  la  lista  detallada  de  cambios  que  hemos  in¬ 
troducido  en  nuestro  directorio  de  trabajo. 


Tabla  de  comandos  de  Subversión 


Tabla  2.  Descripción  de  los  principales  comandos  de  Subversión  (comando  svn) 


Comando 

Descripción 

add 

Añade  un  nuevo  archivo  o  un  conjunto  de  archivos  de  un  directorio  al 
repositorio. 

blame  (praise,  annotate,  ann) 

Muestra  la  última  revisión  del  archivo  indicando  el  número  de  revisión 
de  cada  línea  del  archivo  y  qué  usuario  fue  el  último  que  la  modificó. 

cat 

Examina  las  diferencias  entre  diferentes  versiones  de  un  archivo. 

checkout  (co) 

Esta  operación  es  la  que  realizamos  cuando  queremos  obtener  una  copia 
de  los  archivos  del  repositorio  en  nuestra  máquina. 

cleanup 

Limpia  nuestro  directorio  de  trabajo  de  posibles  operaciones  no  finalizadas 
o  archivos  bloqueados. 

commit 

Acción  con  la  que  enviamos  los  cambios  que  hemos  realizado  en  nuestro 
directorio  de  trabajo  al  repositorio  central  del  servidor. 

copy  (cp) 

Copia  un  archivo  en  nuestro  directorio  de  trabajo  o  repositorio  manteniendo 
el  histórico  del  mismo. 

delete  (del,  remove,  rm) 

Elimina  archivos  y  directorios  permanentemente  del  repositorio. 

diff  (di) 

Muestra  las  diferencias  de  un  archivo  o  grupo  de  archivos  entre  nuestro 
directorio  de  trabajo  al  repositorio  central  del  servidor. 

export 

Exporta  una  copia  del  repositorio. 

help  (?,  h) 

Muestra  la  ayuda  del  programa. 

import 

Importa  archivos  al  repositorio. 

info 

Muestra  información  sobre  nuestro  directorio  de  trabajo  del  repositorio. 

list  (Is) 

Muestra  los  archivos  que  hay  en  el  repositorio. 

log 

Muestra  el  archivo  de  registro  para  un  archivo  o  conjunto  de  archivos. 

merge 

Aplica  las  diferencias  entre  dos  versiones  de  un  archivo  al  nuestro  directorio 
de  trabajo. 
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Comando 


Descripción 


mkdir 

Crea  un  directorio  en  el  repositorio. 

move  (mv,  rename,  ren) 

Mueve  o  cambia  de  nombre  un  archivo  en  el  repositorio. 

propdel  (pdel,  pd) 

Elimina  una  propiedad  con  su  valor  de  un  archivo,  conjunto  de  archivos 
o  directorio. 

propedit  (pedit,  pe) 

Edita  una  propiedad  usando  un  editor  externo. 

propget  (pget,  pg) 

Muestra  el  valor  de  una  propiedad  en  un  archivo,  conjunto  de  archivos 
o  directorio. 

proplist  (plist,  pl) 

Lista  todas  las  propiedades  en  un  archivo,  conjunto  de  archivos  o  directorio. 

propset  (pset,  ps) 

Establece  el  valor  de  una  propiedad  en  un  archivo,  conjunto  de  archivos  o 
directorio. 

resolved 

Elimina  el  estado  de  conflicto  en  archivos  y  directorios. 

revert 

Deshace  los  cambios  introducidos  en  un  directorio  de  trabajo  de  un  archivo. 

status  (stat,  st) 

Muestra  el  estado  de  archivos  y  directorios. 

5.8.  Conclusión 

La  tabla  que  viene  a  continuación  contiene  una  descripción  de  los 
principales  comandos  de  Subversión  (comando  svn). 

Los  sistemas  de  control  de  versiones  son  la  columna  vertebral,  que  pro¬ 
pician  que  grupos  de  personas  trabajen  de  forma  conjunta  en  el  desa¬ 
rrollo  de  proyectos.  Estos  sistemas  permiten  a  miles  de  usuarios  en 
localizaciones  geográficas  diferentes  trabajar  colaborativamente  en  el 
desarrollo  de  software  libre. 

Hemos  aprendido  a  usar  tanto  la  parte  cliente,  como  la  servidor,  de 
CVS  ( concurrent  versions  system )  que  es  el  sistema  de  control  de  ver¬ 
siones  utilizado  actualmente  en  el  mundo  del  software  libre.  Hemos 
visto  también  Subversión,  un  producto  de  control  de  versiones  relati¬ 
vamente  ¡oven,  nació  en  el  año  2001,  que  tiene  como  objetivo  sol¬ 
ventar  las  principales  carencias  de  CVS  y  que  ya  han  comenzado  a 
adoptar  muchos  proyectos  en  sustitución  de  CVS. 

Con  los  conocimientos  adquiridos  de  ambos  productos,  somos  per¬ 
fectamente  capaces  de  poder  obtener  una  copia  de  trabajo  de  cual¬ 
quier  proyecto  libre,  enviar  mejoras,  o  instalar  nuestro  propio  servicio 
de  control  de  versiones. 
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5.9.  Otras  fuentes  de  referencia  e  información 

Control  de  versiones  con  Subversión  (versión  libre). 
http://svnbook.red-bean.com/ 

Notas  de  uso  de  CVS.  http://www.cs.columbia.edu/~hgs/cvs/ 

Open  Source  Development  with  CVS  (3.Q  ed.)  (versión  libre). 
http://cvsbook.red-bean.com/ 

Source  Control. 

http://softwa  re.ericsink.com/scm/source_control.html 

Tarjeta  de  referencia  con  los  comandos  y  opciones  de  CVS. 

http://refcards.com/refcards/cvs/index.html 
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6.  Gestión  de  software 


6.1 .  Introducción 

El  avance  del  sistema  operativo  GNU/Linux,  en  estos  momentos  el 
mayor  exponente  del  software  libre,  ha  hecho  evolucionar  la  manera 
en  la  que  el  software  es  distribuido  en  este  tipo  de  entornos.  El  prin¬ 
cipal  motivo  ha  sido  la  necesidad  de  empaquetar  de  forma  homogé¬ 
nea  y  consistente  el  software  ¡unto  con  la  base  del  sistema  operativo. 


La  gran  variedad  de  distribuciones  de  GNU/Linux  dirigidas  a  distin¬ 
tos  fines  y  usuarios,  también  está  haciendo  que  se  desarrollen  nuevos 
sistemas  de  distribución  de  software,  que  aunque  con  una  base  co¬ 
mún,  difieren  en  la  forma  de  organizar  y  relacionar  el  software  entre 
sí  y  con  sus  componentes  internos. 


6.2.  Objetivos 


Con  la  lectura  de  este  capítulo,  el  lector  debe  ser  capaz  de  alcanzar 
los  objetivos  siguientes: 


•  Analizar  los  sistemas  de  distribución  y  compresión  tradicionales, 
de  forma  individual  y  en  conjunción,  para  posteriormente  estudiar 
los  dos  principales  sistemas  de  distribución,  rpm  y  deb,  entrando 
no  sólo  en  su  manejo,  sino  en  su  creación. 


•  Conocer  los  principales  front-ends  o  software  gráfico  de  gestión 
de  paquetes  para  acercarnos  más  a  la  realidad  existente. 


El  lector,  por  lo  tanto,  deberá  finalizar  el  capítulo  conociendo  y  ma¬ 
nejando  todos  los  sistemas  expuestos,  tanto  desde  el  punto  de  vista 
funcional  como  de  creación. 
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Software  libre 


6.3.  El  empaquetador  universal:  tar 

Uno  de  los  principales  problemas  a  la  hora  de  distribuir,  copiar  o  al¬ 
macenar  archivos  es  el  de  mantener  intactos  todos  los  "metadatos" 
asociados,  como  pueden  ser  la  fecha  de  creación,  los  permisos  de 
ejecución  o  el  usuario  y  grupo  al  que  pertenecen.  En  la  distribución 
también  es  recomendable  que  cada  elemento  de  software  sea  pre¬ 
sentado  como  un  archivo  único  fácilmente  identificable. 


Para  todas  estas  necesidades  existe  la  utilidad  tar. 


Aunque  originalmente  pensada  para  realizar  copias  de  respaldo  a 
cinta  ("Tape  ARchiver"  o  archivador  en  cinta),  su  uso  en  entornos  Linux 
ha  venido  motivado  principalmente  por  su  facilidad  de  manejo  y  ver¬ 
satilidad  en  la  tarea  concreta  de  realizar  copias  idénticas,  tanto  de 
archivos  como  estructuras  de  directorio  completas. 


La  sintaxis  básica  de  la  utilidad  tar  es  la  siguiente: 


tar  modo  [opciones]  [-f  fichero_tar]  [ficheros_origen] 


La  utilidad  tar  puede  operar  tanto  sobre  ficheros  especificados  ex¬ 
plícitamente,  como  sobre  la  entrada  y  salida  estándar  del  programa 
(por  ejemplo  con  redirecciones). 


Contenido 

complementario 


Utilidad  tar 

c:  crear 
x:  eXtraer 
t:  lisTar 


Las  opciones  se  componen  de  un  comando  principal  ("modo  de  ope¬ 
ración")  que  define  si  está  creando  (c),  extrayendo  (x),  listando  (t),  etc. 
el  contenido  del  fichero  empaquetado. 


Con  la  opción  f  nombre_f  ichero  especificamos  que  se  va  a  ope¬ 
rar  sobre  un  fichero  tar  (y  no  sobre  la  entrada/salida  estándar). 


Nota 


Por  motivos  de  seguridad, 
los  ejemplos  no  se  hacen 
como  superusuario  (root), 
salvo  que  se  diga  lo  contrario. 


Añadiendo  v  ("verbose"  =  detallado)  obtenemos  un  informe  de  las 
operaciones  que  va  realizando  tar,  lo  que  puede  ser  especialmente 
útil  para  detectar  errores,  o  simplemente  mantener  la  calma  cuando  se 
manejan  grandes  cantidades  de  datos  y  tar  parece  "no  hacer  nada". 

Veamos  un  ejemplo  de  su  uso. 
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Empezaremos  creando  un  directorio  temporal: 


$  mkdir  /tmp/test 
$  cd  /tmp/test 


Para  llenarlo  rápidamente  de  ficheros,  podemos  hacer: 


$  cp  /dev/null  /tmp/test/f icherol 
$  cp  -r  /tmp/test/  /tmp/test/directorio 
$  chmod  400  /tmp/test/f icherol 
$  ls  -1  /tmp/test 
total  0 

drwxr-xr-x  2  user  user  60  Nov  17  18:03  directorio/ 
-r -  1  user  user  0  Nov  17  18:03  ficherol 


Ahora,  supongamos  que  queremos  hacer  una  copia  de  seguridad 
del  directorio  test,  podríamos  hacer  lo  siguiente: 


$  cd  / tmp 

$  tar  cvf  /tmp/test . tar  test 
test/ 

test /directorio/ 
test /director io/f icherol 
test/f icherol 
$  ls  -1  /tmp/test . tar 

-rw-r— r—  1  user  user  10240  nov  17  18:03  /tmp/test . tar 


Si  ahora  borrásemos  el  directorio  test: 


$  rm  -rf  /tmp/test 
$  ls  test 

ls:  test:  No  such  file  or  directory 


Podríamos  restaurarlo  completamente  desde  el  fichero  test,  tar: 


$  cd  / tmp 

$  tar  xvf  /tmp/test . tar 
test/ 

test /directorio/ 
test /director io/f icherol 
test/ ficherol 
$  ls  -1  /tmp/test 
total  0 

drwxr-xr-x  2  user  user  60  Nov  17  18:03  directorio/ 
-r -  1  user  user  0  Nov  17  18:03  ficherol 
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Se  puede  apreciar  que  el  fichero  /tmp/test/ficherol  se  ha  res¬ 
taurado  con  los  mismos  permisos,  usuario  y  fecha  que  tenía  cuando 
fue  almacenado  con  tar. 

También  podemos  consultar  en  cualquier  momento  cuál  es  el  conte¬ 
nido  de  un  fichero  tar: 


$  tar  tvf  test. tar 
drwxr-xr-x  user/user 
drwxr-xr-x  user/user 
-rw-r — r--  user/user 
-r -  user/user 


0  2004-11-17  18:03:49  test/ 

0  2004-11-17  18:03:49  test/directorio/ 

0  2004-11-17  18:03:49  test/directorio/ficherol 
0  2004-11-17  18:03:48  test/f icherol 


6.3.1.  Comprimiendo:  qzip 

La  mayoría  de  los  ficheros  almacenados  en  un  ordenador  suelen 
estarlo  de  tal  forma  que  se  puedan  leer  de  disco  y  utilizar  lo  más 
rápidamente  posible.  Esto  implica  que  aparezca  información  alma¬ 
cenada  en  bloques  de  tamaño  fijo  (independientemente  de  si  están 
llenos  o  no),  información  de  un  conjunto  de  caracteres  reducido 
(por  ejemplo,  texto  legible  directamente)  y  otras  formas  de  almace¬ 
namiento  en  las  que  no  se  tiene  demasiado  en  cuenta  el  espacio 
que  ocupan. 

Sin  embargo,  toda  información  puede  ser  codificada  de  forma  que 
se  reduzca  el  espacio  que  ocupa  sin  perder  parte  de  la  misma,  se  tra¬ 
ta  de  ficheros  de  texto,  ejecutables  o  de  cualquier  otro  tipo,  puesto 
que  siempre  aparecen  en  ellos  secuencias  de  bytes  que  se  repiten  y 
son  susceptibles  de  ser  comprimidas  ("simplificadas"). 

Una  herramienta  muy  útil  para  la  compresión  y  descompresión  de 
distintos  formatos  basados  en  la  codificación  Lempel-Ziv  es  la  utili¬ 
dad  gzip/gunzip. 

Basada  en  un  documento  de  1977  por  J.  Ziv  y  A.  Lempel  sobre  un 
algoritmo  universal  de  compresión  secuencial,  esta  codificación  per¬ 
mite  comprimir  y  descomprimir  los  ficheros  directamente  mientras  se 
leen  byte  tras  byte. 

Al  igual  que  la  mayoría  de  las  utilidades  del  sistema,  permite  com¬ 
primir  y  descomprimir  tanto  desde  entrada  estándar  como  desde  fi¬ 
chero,  grabando  el  resultado  en  otro  fichero  o  en  la  salida  estándar. 
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La  sintaxis  básica  es  muy  simple  (en  orden:  comprimir,  descomprimir): 


gzip  nombre_f ichero 
gunzip  nombre_f ichero . gz 


Si  no  se  especifican  más  opciones,  gzip  comprime  el  fichero 
nombre_f ichero  y  lo  reemplaza  con  el  resultado  guardado  aña¬ 
diendo  la  extensión  .  gz  como  nombre_f  ichero  .  gz. 


Inversamente,  gunzip  descomprime  el  fichero  nombre_f ichero  .gz 
y  lo  reemplaza  con  el  resultado  guardado  quitando  la  extensión  .  gz 
como  nombre  fichero. 


Debido  a  este  funcionamiento  y  a  la  capacidad  de  compresión  se- 
cuencial,  es  el  complemento  ideal  para  tar. 

En  los  ejemplos  anteriores  sólo  se  habían  manejado  ficheros  "va¬ 
cíos",  y  aun  así  se  puede  observar  que  el  fichero  .tar  ocupa  más  de 
1 0.000  bytes.  Esto  es  debido  a  que  internamente  la  información  se  al¬ 
macena  en  bloques  de  como  mínimo  512  bytes  (incluido  un  bloque  por 
fichero  con  los  metadatos)  y  se  graba  en  bloques  de  10.240  bytes. 

Normalmente,  esto  no  supone  un  problema  con  ficheros  de  tamaño 
considerable,  sin  embargo,  es  un  factor  a  tener  en  cuenta  si  se  quiere 
almacenar  gran  número  de  ficheros  pequeños. 

En  todo  caso,  veamos  cómo  podemos  usar  gzip/gunzip  tanto  por 
separado  como  ¡unto  con  tar. 


Supongamos  que  ahora,  una  vez  creado  / tmp/test .  tar,  quere¬ 
mos  hacer  que  ocupe  menos.  Sólo  hay  que  ejecutar: 

$  ls  -1  /tmp/test . tar 

-rw-r— r—  1  user  user  10240  Nov  17  18:03  /tmp/test . tar 
$  gzip  /tmp/test. tar 


Y  obtendremos  un  fichero  comprimido: 


$  ls  -1  /tmp/test . tar . gz 

-rw-r— r—  1  user  user  191  Nov  17  18:03  /tmp/test . tar . gz 
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Obsérvese  que  al  comprimir  el  fichero  NO  se  ha  cambiado  ni  el 
usuario,  ni  los  permisos,  ni  la  fecha  del  mismo.  En  cambio  SI  que  se 
ha  borrado  la  copia  original: 

$  ls  -1  /tmp/test . tar 

ls:  /tmp/test . tar :  No  such  file  or  directory 


Veamos  si  podemos  descomprimirlo: 

$  gunzip  /tmp/test . tar . gz 
$  ls  -1  /tmp/test . tar 

-rw-r— r—  1  user  user  10240  Nov  17  18:03  /tmp/test . tar 
$  ls  -1  /tmp/test . tar . gz 

ls:  /tmp/test . tar . gz :  No  such  file  or  directory 


El  fichero  .tar.gz  ha  sido  borrado  tras  la  creación  del  .tar  descom¬ 
primido. 

Ahora,  supongamos  que  queremos  crear  el  fichero  .tar.gz,  pero  sin 
el  paso  intermedio  de  crear  el  .tar  y  ocupar  tanto  espacio  en  disco 
(igual  a:  los  datos  originales  +  metadatos  +  el  fichero  .tar.gz  antes 
de  ser  borrado  el  .tar). 

Para  estos  casos  tenemos  distintas  opciones. 

Por  un  lado  se  pueden  usar  redirecciones  aprovechando  que  tanto 
tar  como  gzip  pueden  trabajar  con  la  salida  y  entrada  estándar: 


$  cd  / tmp 

$  tar  cv  test  I  gzip  >  /tmp/test. tar .gz 
test/ 

test/f icherol 
test /directorio/ 
test /directorio/ f icherol 
$  ls  -1  /tmp/test . tar . gz 

-rw-r— r—  1  user  user  184  Nov  17  18:03  /tmp/test . tar . gz 

O  podemos  aprovechar  directamente  una  de  las  opciones  de  tar, 
la  z  (zip): 
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$  cd  / tmp 

$  tar  czvf  /tmp/test . tar . gz  test 


test/ 

test/f icherol 
test /directorio/ 
test /director io/f icherol 
$  ls  -1  /tmp/test . tar . gz 

-rw-r— r—  1  user  user  184  Nov  17  18:03  /tmp/test . tar . gz 


6.3.2.  Usando  tar,  azip,  y  unos  disauetes 

Una  situación  que  puede  presentarse  al  intentar  grabar  una  serie  de 
archivos  en  un  medio  como  un  disquete  es  que  haya  algún  archivo 
más  grande  que  la  capacidad  del  disco  en  sí.  Tanto  en  este  caso 
como  para  optimizar  el  espacio  en  los  disquetes,  lo  más  cómodo  es 
poder  partir  el  conjunto  de  los  datos  que  hay  que  grabar  en  trozos 
del  tamaño  de  cada  disquete. 

Según  esto,  se  ha  establecido  la  opción  M  (Multi-volumen)  de  tar. 


Supongamos  que  tenemos  tres  archivos  aleatorios  de  1  MB  cada 
uno: 


$  dd  bs=1024  count=1024  <  /dev/urandom  >  /tmp/test/f icherol 

$  dd  bs=1024  count=1024  <  /dev/urandom  >  /tmp/test/f ichero2 

$  dd  bs=1024  count=1024  <  /dev/urandom  >  /tmp/test/f ichero3 

-rw-r— r—  1  root  root  1048576  nov  17  18:03  /tmp/f icherol 

-rw-r— r—  1  root  root  1048576  nov  17  18:03  /tmp/f ichero2 

-rw-r— r—  1  root  root  1048576  nov  17  18:03  /tmp/f ichero3 


Si  intentásemos  grabarlos  en  disquetes  de  1.4  MB  (1440  KB  = 
1 474560  bytes),  habría  que  elegir  entre  guardar  cada  fichero  por  se¬ 
parado,  o  comprimir  los  ficheros  por  separado  y  esperar  que  dos  o 
más  cualesquiera  ocupasen  menos  de  1 .4  MB: 


$  gzip  /tmp/test/f icherol 
$  gzip  /tmp/test/f ichero2 
$  gzip  /tmp/test/fichero3 
$  ls  -1  /tmp/test/fichero* .  gz 

-rw-r— r--  1  root  root  1048763  nov  17  18:03  /tmp/f  icherol .  gz 

-rw-r— r—  1  root  root  1048763  nov  17  18:03  /tmp/f ichero2 . gz 

-rw-r— r—  1  root  root  1048763  nov  17  18:03  /tmp/fichero3 . g 
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o 


En  este  caso  los  ficheros  no  se  comprimen  debido  a  que  se  crearon  con¬ 
teniendo  sólo  secuencias  de  bytes  aleatorios,  difícilmente  comprimibles. 

Para  solucionar  este  problema,  podemos  recurrir  a  la  opción  M  (mul- 
ti-volumen)  de  tar  comprimiendo  directamente  en  el  disquete: 


$  tar  cMf  /tmp/f loppy/test . tar  /tmp/test/f ichero* 
Prepare  el  volumen  #2  para  'test. tar'  y  pulse  intro: 
Prepare  el  volumen  #3  para  'test. tar'  y  pulse  intro: 


Con  esta  opción  tar  intentará  grabar  el  máximo  posible  de  datos  en 
cada  disco,  posteriormente  pedirá  que  se  cambie  por  uno  vacío,  y  vol¬ 
verá  a  repetir  el  proceso  hasta  que  todos  los  datos  estén  grabados. 

Si  en  vez  de  grabar  directamente  a  disco  lo  que  queremos  es  prepa¬ 
rar  primero  los  ficheros,  podemos  recurrir  a  la  opción  L  (longitud) 
que  nos  permitirá  especificar  la  "longitud  del  medio"  (o  disco)  en 
múltiplos  de  1024  bytes. 

Al  mismo  tiempo,  podemos  poner  más  de  un  fichero  tar  de  salida 
con  repetidas  opciones  f  fichero  (ff  fichero  fichero,  fff 
fichero  fichero  fichero,  ...). 

$  tar  cMfff  /tmp/testl . tar  /tmp/test2 . tar  /tmp/test3 . tar  \ 

>  /tmp/test/f ichero*  -L  1440 
$  ls  -1  /tmp/test? . tar 

-rw-r— r—  1  root  root  1474560  nov  17  18:03  testl.tar 

-rw-r— r—  1  root  root  1474560  nov  17  18:03  test2.tar 

-rw-r— r—  1  root  root  204800  nov  17  18:03  test3.tar 

La  única  limitación  de  tar  es  que,  debido  a  su  uso  de  gzip  para  com¬ 

primir  el  resultado  del  propio  tar,  no  permite  fraccionar  y  comprimir  los 
archivos  al  mismo  tiempo  (esto  es  válido  para  GNU  tar  1.14). 


6.4.  RPM 
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Con  nombre  autorreferente  "RPM  Package  Manager"  (Gestor  de  Pa¬ 
quetes  RPM),  es  un  formato  para  la  distribución  y  gestión  de  paquetes 
de  software  entendidos  en  el  sentido  de  "módulos  funcionales  indivi- 


si  bles".  La  distribución  que  lo  desarrolló  e  implemento  en  primer  lu¬ 
gar  fue  Red  Hat  Linux,  a  la  que  siguieron  Suse  y  Mandrake  entre  otras. 

La  ventaja  de  utilizar  RPM  en  vez  de  ficheros  .tar  (o  .tar.gz)  consiste 
en  las  opciones  adicionales  que  RPM  permite  especificar,  a  la  perso¬ 
na  que  crea  el  paquete,  para  ser  ejecutadas  automáticamente  en  la 
instalación,  desinstalación,  etc.  del  mismo.  De  esta  forma  se  simpli¬ 
fica  al  máximo  la  tarea  al  usuario  final  y,  si  el  paquete  está  creado 
correctamente,  mantiene  una  lista  de  los  paquetes  instalados  y  las 
relaciones  entre  ellos  para  evitar  que  aparezcan  conflictos  entre  los 
ficheros  instalados,  o  pendientes  de  instalar. 


6.4.1.  Trabajar  con  RPM 

Las  fases  del  sistema  RPM  se  pueden  dividir  en  tres  partes: 

1)  El  creador  del  paquete  .rpm 

2)  Una  base  de  datos  de  paquetes  instalados  en  el  sistema  del  usuario 

3)  El  programa  rpm  en  sí 

En  este  caso  nos  vamos  a  ocupar  del  último  punto  (el  programa  rpm) 
y  de  su  relación  con  la  base  de  datos  (segundo  punto)  al  instalar  y 
gestionar  los  distintos  paquetes  .rpm. 


Los  sistemas  de  paquetes  han  hecho  posible  la  creación  de  distribu¬ 
ciones  GNU/Linux,  ya  que  es  una  forma  sencilla  de  distribuirlos  y 
guardar  una  base  de  datos  que  les  dé  consistencia. 

Se  pueden  encontrar  en  los  discos  de  instalación,  en  Internet  dentro 
de  servidores  ftp  con  copias  de  las  distribuciones,  ser  facilitados  por 
los  autores  de  los  programas,  etc. 


Lectura  complementaria 


http://rpmfind.net 

http://freshmeat.net 

ftp://ftp.rediris.es 


Suelen  estar  nombrados  en  el  formato: 


paquete  -  versión  del  software  -  versión-rpm  .  arquitectura  .rpm 


Por  ejemplo,  éstos  son  paquetes  .  rpm: 


gcc-3 .4.3-3.Í386. rpm 
apache- 1 . 3 . 31-7mdk . i58  6 . rpm 
bash-3 . 0-22 . x8  6_64 . rpm 
per 1-5 . 00503-12. alpha . rpm 
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Los  paquetes  .rpm  son  versiones  ejecutables  (compiladas)  de  los  pro¬ 
gramas.  Dado  que  los  programas  bajo  licencias  libres  también  dis¬ 
tribuyen  el  código  fuente,  también  existen  las  versiones  en  código 
fuente  de  los  mismos  paquetes: 


gcc-3 . 4 . 3-3 . src . rpm 
apache- 1 . 3 . 31-7mdk . src . rpm 
bash-3 . 0-22 . src . rpm 
per 1-5 .00503-12. src. rpm 


Como  se  puede  observar,  en  este  caso  sólo  se  ha  sustituido  el  nom¬ 
bre  de  la  arquitectura  para  la  que  está  destinado  el  paquete  por  el 
texto  src.  Esto  es  debido  a  que  un  paquete  de  código  fuente  suele 
estar  preparado  para  compilarse  en  cualquier  arquitectura.  Así,  aun¬ 
que  el  paquete  compilado  para  x8  6_64  tendría  problemas  para  eje¬ 
cutarse  en  un  entorno  PowerPC  (ppc),  el  paquete  de  código  fuente 
puede  ser  compilado  para  dar  lugar  a  ambos  x86_64  y  ppc,  que 
posteriormente  se  podrán  distribuir  e  instalar  directamente  en  estas 
arquitecturas. 

También  pueden  llamarse  con  la  cadena  noarch,  que  significa  es¬ 
trictamente  "independiente  de  arquitectura",  o  nosrc  que  designa¬ 
ría  un  paquete  con  sólo  las  pautas  para  construir  el  ejecutable  a 
partir  del  código  fuente  pero  sin  incluirlo. 

Entre  otras  cosas,  esto  permite  que  se  desarrolle  software  en  una  ar¬ 
quitectura  y  se  use  en  otra  con  sólo  compilar  el  paquete  src.  O  se 
distribuya  sólo  en  formato  src  y  cada  usuario  pueda  compilarlo  a  la 
hora  de  instalar,  sea  para  optimizarlo  para  su  sistema  o  con  el  fin  de 
asegurarse  de  que  la  versión  ejecutable  corresponda  realmente  al 
código  fuente  obtenido  del  programa. 


Contenido 

complementario 


Utilidad  rpm 

i:  instalar 

u:  actualizar  (Update) 
q:  consultar  (Query) 
e:  eliminar 
V:  verificar 


6.4.2.  Instalación 

La  instalación  de  un  paquete  en  versión  ejecutable  no  supone  mayor 
dificultad  con  la  opción  -i  de  rpm: 


$  rpm  -ivh  nc-1 . 10-18mdk. i586 . rpm 
Preparing...  #####################  [100%] 
1 : nc  #####################  [100%] 
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La  opción  v  (minúscula)  hace  que  se  muestren  los  pasos  que  se  van 
dando.  La  h  muestra  las  barras  de  progreso  (#). 

Como  se  ha  dicho  antes,  RPM  permite  asegurarse  de  que  no  hay 
conflictos  entre  paquetes.  Una  de  las  formas  de  conseguirlo  es  espe¬ 
cificando  en  cada  paquete  qué  otros  harán  falta  para  su  correcto 
funcionamiento.  Esto  es  lo  que  se  llaman  "dependencias"  (los  paque¬ 
tes  "dependen"  unos  de  otros). 

Junto  con  la  base  de  datos  listando  los  paquetes  instalados,  esto 
hace  que  al  instalar  un  paquete  sea  posible  detectar  la  falta  de  algu¬ 
na  dependencia  (otro  paquete)  necesaria  para  que  funcione  correc¬ 
tamente: 

$  rpm  -ivh  gaim-1 . 0 . 3-lmdk . i58 6 . rpm 
error:  Failed  dependencies: 

libgaim-remote  =  1:1.0. 3-lmdk  is  needed  by  gaim-1 . 0 . 3-lmdk 


Las  dependencias  pueden  ser  de  una  versión  concreta  o  de  una  com¬ 
paración  booleana  (por  ejemplo:  >=  ,  que  significaría  "mayor  o  igual 
a  la  pedida"). 

Para  resolverlas  será  necesario  descargar  el  paquete  que  falta  e  ins¬ 
talarlo  antes  o  ¡unto  al  paquete  que  lo  necesita: 

$  rpm  -ivh  gaim-1 . 0 . 3-lmdk. i586 . rpm  \ 

>  libgaim-remoteO-1 . 0 . 3-lmdk. i586 . rpm 

Preparing...  #####################  [100%] 

1 : libgaim-remoteO  #####################  [  50%] 

2 : gaim  #####################  [100%] 

En  este  caso  rpm  se  encarga  del  orden  correcto  en  el  que  deben  ser 
instalados  cada  uno  de  los  paquetes. 

Si  sólo  se  desea  comprobar  si  es  posible  o  no  instalar  un  paquete  deter¬ 
minado,  pero  sin  instalarlo  realmente,  se  puede  usar  la  opción  -test: 

$  rpm  -ivh  — test  gaim-1 . 0 . 3-lmdk. i586 . rpm  \ 

>  libgaim-remoteO-1 . 0 . 3-lmdk. i586 . rpm 

Preparing...  #####################  [100%] 

$  echo  $? 

0 
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El  valor  de  retorno  de  esta  opción  se  puede  usar  para  automatizar 
las  decisiones  de  instalación: 

$  rpm  -ivh  --test  gaim-1 . 0 . 3-lmdk . i586 . rpm 
error:  Failed  dependencies: 

libgaim-remote  =  1:1.0. 3-lmdk  is  needed  by  gaim-1 . 0 . 3-lmdk 
libgaim-remote . so . 0  is  needed  by  gaim-1 . 0 . 3-lmdk 
$  echo  $? 

1 


Si  fallan  las  dependencias,  también  se  puede  elegir  ignorar  este  fallo 
e  instalar  el  paquete  de  todas  formas  con  la  opción  --nodeps,  aun¬ 
que  probablemente  luego  no  funcione: 


$  rpm  -ivh  --nodeps  gaim-1 . 0 . 3-lmdk. i586 . rpm 
Preparing...  #####################  [100%] 

2 : gaim  #####################  [100%] 

En  caso  de  que  dos  paquetes  entrasen  en  conflicto: 


$  rpm  -ivh  --nodeps  gaim-1 . 0 . 2-lmdk . i58 6 . rpm 
Preparing. . .  #####################  [100%] 

package  gaim-1 . 0 . 3-lmdk  (which  is  newer  than  gaim-1 . 0 . 2-lmdk)  is  already  installed 

file  /usr/bin/gaim  from  install  of  gaim-1 . 0 . 2-lmdk  conflicts  with  file  from  package  gaim-1 . 0 . 3-lmdk 
file  /usr/bin/gaim- remóte  from  install  of  gaim-1 . 0 . 2-lmdk  conflicts  with  file  from  package  gaim-1 . 0 . 3-lmdk 
file  /usr/lib/gaim/autorecon.  so  from  install  of  gaim-1 . 0 . 2-lmdk  conflicts  with  file  from  package  gaim-1 . 0 . 3-lmdk 
file  /usr/lib/gaim/docklet . so  from  install  of  gaim-1 . 0 . 2-lmdk  conflicts  with  file  from  package  gaim-1 . 0 . 3-lmdk 


Nota 


Advertimos  que  esta  forma 
de  instalación  ignora  las  re¬ 
comendaciones  de  rpm  y, 
por  lo  tanto,  del  autor  del 
programa  o  del  encargado 
de  crear  y  testear  el  paque¬ 
te.  Esto  puede  conducir  a  un 
sistema  inestable  y  distintos 
conflictos  entre  programas, 
que  normalmente  no  serán 
tomados  en  cuenta  por  los 
desarrolladores. 


Se  puede  buscar  alguno  compatible  con  el  instalado  (o  actualizar  és¬ 
te),  o  forzar  la  instalación  del  nuevo  paquete  independientemente  de 
los  avisos.  En  este  caso,  es  probable  que  el  paquete  no  funcione  co¬ 
rrectamente,  que  sobreescriba  partes  de  otro  paquete,  etc.  Hay  distin¬ 
tas  opciones  que  permiten  saltarse  distintas  partes  (--replacepkgs, 
--replacef iles,  --oldpackage)  de  la  comprobación,  o  saltarse 
todas  con  --forcé: 


$  rpm  -ivh  --nodeps  --forcé  gaim-1 . 0 . 3-lmdk . i58 6 . rpm 
Preparing...  #####################  [100%] 

2 : gaim  #####################  [100%] 
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6.4.3.  Actualización 


Para  actualizar  un  paquete,  lo  más  obvio  sería  desinstalar  la  versión 
antigua  e  instalar  en  su  lugar  la  nueva.  Sin  embargo,  esto  puede 
romper  algunas  dependencias  de  paquetes  que  son  imprescindibles 
para  el  que  intentamos  actualizar. 

Esto  se  puede  evitar  con  la  opción  -U  ("Update"  =  actualizar)  de  rpm. 

Su  uso  es  igual  que  el  de  la  -i  para  instalar,  con  la  diferencia  de  que 
si  alguna  de  las  dependencias  que  entran  en  conflicto  con  la  instala¬ 
ción  es  del  mismo  paquete  pero  con  versión  anterior,  éste  será  elimi¬ 
nado  y  reemplazado  por  el  nuevo  de  forma  automática.  Primero 
instalamos  una  versión  anterior: 


$  rpm  -ivh  gaim-1 . 0 . 2-lmdk. i586 . rpm  \ 

>  libgaim- remoteO -1 . 0 . 2-lmdk . i58 6 . rpm 

Preparing. . .  #####################  [100%] 

1 : libgaim-remoteO  #####################  [  50%] 

2 : gaim  #####################  [100%] 

$  rpm  -q  gaim  libgaim-remoteO 
gaim-1 . 0 . 2-lmdk 
libgaim-remoteO-1 . 0 . 2-lmdk 


Y  posteriormente  actualizamos  a  una  versión  superior: 

$  rpm  -Uvh  gaim-1 . 0 . 3-lmdk . i58 6 . rpm  \ 

>  libgaim- remoteO -1 . 0 . 3-lmdk. i586 . rpm 

Preparing. . .  #####################  [100%] 

1: libgaim-remoteO  #####################  [  50%] 

2: gaim  #####################  [100%] 

$  rpm  -q  gaim  libgaim-remoteO 
gaim-1 . 0 . 3-lmdk 
libgaim-remoteO-1 . 0 . 3-lmdk 


Se  puede  apreciar  que  rpm  detecta  que  la  versión  nueva  es  una  ac¬ 
tualización  de  la  anterior  y  no  presenta  mensaje  de  error  por  el  con¬ 
flicto  entre  paquetes  y  ficheros  instalados. 

Durante  una  actualización  se  mantienen  los  ficheros  de  configuración 
de  los  paquetes  salvo  que  los  nuevos  sean  muy  diferentes  y  con  los 
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antiguos  posiblemente  no  funcionasen  los  paquetes,  en  cuyo  caso  rpm 
hace  una  copia  de  seguridad  (añadiendo  la  extensión  .rpmsave  al  nom¬ 
bre  del  fichero)  e  instala  en  su  lugar  la  nueva  versión  del  mismo.  En  otras 
ocasiones,  cuando  el  fichero  antiguo  es  compatible  con  la  nueva  versión 
del  programa  pero  hay  un  fichero  nuevo  con  otras  opciones,  es  el  nuevo 
el  que  se  salva  aparte  (añadiendo  la  extensión  .rpmnew) 

6.4.4.  Consulta 

La  base  de  datos  de  paquetes  instalados,  así  como  toda  la  informa¬ 
ción  relativa  al  paquete,  pueden  ser  consultados  con  la  opción  -q 
("Query"  =  consultar)  de  rpm: 

$  rpm  -q  gaim 
gaim-1 . 0 . 3-lmdk 

Para  ver  una  lista  de  todos  los  paquetes  instalados,  podemos  usar  la 
opcion  a  ("All"  =  todos): 

$  rpm  -qa 

libltdl3-l . 5 . 6-4mdk 
termcap-11 . 0 . l-8mdk 
libofx-0 . 6 . 6-2mdk 

Dado  que  esta  lista  suele  ser  bastante  larga,  para  ver  los  paquetes 
instalados  es  más  cómodo  usar: 

$  rpm  -qa  |  less 

Para  consultar  los  datos  de  un  paquete  -i  (información): 


$  rpm  -qi  gaim 


Ñame 


gaim 


Relocations :  (not  relocatable) 


Versión 


1.0.3 


Vendor:  Mandrakesoft 


Release 


lmdk 


Build  Date:  vie  12  nov  2004  23:29:22  CE 


Install  Date:  sáb  20  nov  2004  08:28:52  CET 


Build  Host:  n4.mandrakesoft.com 


Group 


Networking/Instant  messaging  Source  RPM:  gaim-1 . 0 . 3-lmdk. src . rpm 


Size 


8514053 


License:  GPL 


Signature  :  DSA/SHA1,  vie  12  nov  2004  23:40:27  CET,  Key  ID  dd684d7a26752624 
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Packager 

URL 


Pascal  Terjan  <pter j an@mandrake . org> 
http : //gaim. sourceforge . net/ 

Summary  :  A  GTK+  based  multiprotocol  instant  messaging  Client 

Description  : 

Gaim  allows  you  to  talk  to  anyone  using  a  variety  of  messaging 
protocols,  including  AIM  (Oscar  and  TOC) ,  ICQ,  IRC,  Yahoo!, 

MSN  Messenger,  Jabber,  Gadu-Gadu,  Napster,  and  Zephyr.  These 
protocols  are  implemented  using  a  modular,  easy  to  use  design. 

To  use  a  protocol,  just  load  the  plugin  for  it. 

Gaim  supports  many  common  features  of  other  clients,  as  well  as  many 
unique  features,  such  as  perl  scripting  and  C  plugins . 

Gaim  is  NOT  affiliated  with  or  endorsed  by  AOL. 

Donde  pueden  verse  diferentes  datos  relativos  al  paquete. 

Si  es  de  un  paquete  no  instalado  en  el  sistema,  y  que  por  lo  tanto  no 
está  en  la  base  de  datos,  teniendo  el  fichero  .rpm  podemos  hacer  re¬ 
ferencia  a  él  con  -p  (fichero): 

$  rpm  -qp  gaim-1 . 0 . 3-lmdk . i58 6 . rpm 
gaim-1 . 0 . 3-lmdk 


La  lista  de  ficheros  contenidos  en  el  paquete  puede  consultarse  con 
-1.  Añadiendo  -v  se  muestran  también  los  datos  de  cada  fichero: 

$  rpm  -qlv  gaim 


-rwxr-xr-x 

1 

root 

root 

853644 

nov 

12 

23:29 

/usr/bin/gaim 

-rwxr-xr-x 

1 

root 

root 

7608 

nov 

12 

23:29 

/usr/bin/gaim-remote 

drwxr-xr-x 

2 

root 

root 

0 

nov 

12 

23:29 

/usr/lib/gaim 

-rwxr-xr-x 

1 

root 

root 

8676 

nov 

12 

23:29 

/usr/lib/gaim/autorecon .  so 

También  se  puede  solicitar  sólo  determinado  "tipo"  de  ficheros, 
como  documentación  -d: 

$  rpm  -qld  coreutils 

/usr/share/doc/ coreutils -5 . 2 . 1/README 


O  sólo  los  de  configuración: 

$  rpm  -qlc  coreutils 
/ etc/DIR_COLORS 
/etc/pam. d/su 
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De  esta  forma  se  pueden  automatizar  tareas  relacionadas  con  la  do¬ 
cumentación  (p.  e¡.  creación  de  índices)  o  la  configuración  (p.  e¡.  co¬ 
pia  de  seguridad)  de  los  paquetes. 


6.4.5.  Desinstalación 

La  desinstalación  de  un  paquete  se  lleva  a  cabo  con  la  opción  -e. 

Igual  que  en  la  instalación,  si  se  intenta  quitar  un  paquete  del  que 
dependen  otros,  rpm  avisará  con  un  mensaje  de  error: 


$  rpm  -ev  libgaim-remoteO 
error:  Failed  dependencies: 

libgaim-remote  =  1 : 1 . 0 . 3-lmdk  is  needed  by  (installed)  gaim-1 . 0 . 3-lmdk 
libgaim-remote . so . 0  is  needed  by  (installed)  gaim-1 . 0 . 3-lmdk 


Y,  al  igual  que  antes,  es  suficiente  con  especificar  a  la  vez  todos  los 
paquetes  que  se  van  a  desinstalar: 

$  rpm  -ev  libgaim-remoteO  gaim 


6.4.6.  Verificación 


Contenido 

complementario 


Tipos  de  verificaciones 

S:  tamaño  (s/ze)  del  fichero 
M:  modo  (permisos) 

5:  suma  MD5 

D:  dispositivo  (mayor/menor) 
L:  destino  del  enlace 
U:  usuario  (propietario) 

G:  grupo  (propietario) 

T:  fecha  (time)  del  fichero 


Otra  de  las  funciones  interesantes  de  RPM  es  la  posibilidad  de  verifi¬ 
car  el  estado  de  cada  fichero  instalado  para  detectar  posibles  modi¬ 
ficaciones. 

En  cada  paquete  se  guarda  la  información  sobre  el  tamaño,  suma 
de  comprobación,  propietarios,  etc.  de  cada  fichero.  A  la  hora  de 
instalarlo,  estos  datos  también  son  almacenados  en  la  base  de  datos 
de  RPM,  de  forma  que  luego  pueden  ser  utilizados  con  el  fin  de  com¬ 
pararlos  con  los  mismos  datos  obtenidos  de  los  ficheros  presentes  en 
el  sistema  y  verificar  que  éstos  no  han  sido  modificados. 


La  sintaxis  básica  se  centra  en  la  opción  --verify  (-V)  de  rpm: 

rpm  -V  coreutils 
S.5....T  c  /etc/pam. d/su 
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Por  cada  fichero  distinto  a  su  correspondiente  del  paquete  original, 
se  muestra  una  línea  con  la  lista  de  los  cambios  detectados  y  el  tipo 
de  fichero:  configuración,  documentación,  ghost  (no  incluido  pero 
creado),  licencia,  readme  ('leeme').  No  se  muestran,  sin  embargo, 
diferencias  para  ficheros  no  instalados  originalmente  con  el  paquete. 

Otra  forma  de  verificación  consiste  en  la  validación  de  la  firma 
OpenPGP  (gpg  del  paquete  en  sí  por  medio  de  la  opción  -checksig: 

#  rpm  --checksig  XllR6-contrib-6 . 7 . 0-4 . 2 . lOlmdk. i586 . rpm 
XllR6-contrib-6 . 7 . 0-4 . 2 . lOlmdk . i58  6 . rpm: 

Header  SHA1  digest:  OK  (caa530fe83f24cbdeefbfbfb0db53f21cd860e07) 
MD5  digest:  OK  (023c21cf 6ef Of 6f 0841f fa0b9010ac43) 

V3  DSA  signature:  OK,  key  ID  22458a98 

Para  esto  la  parte  pública  de  la  clave  gpg  con  la  que  esté  firmado  el 
paquete  debe  estar  incluida  en  el  anillo  de  claves  del  usuario  que  eje¬ 
cute  rpm,  o  en  el  especificado  por  la  macro  %_gpg_path. 


6.4.7.  Creación  de  paquetes  v  gestión  de  parches 

La  creación  de  paquetes  se  centra  en  la  utilidad  rpmbuild  y  un  fichero 
de  .spec  que  especifique  los  metadatos  y  pasos  a  dar  en  la  compila¬ 
ción,  instalación  y  desinstalación  de  cada  paquete. 


Quizá  la  forma  más  simple  sea  la  creación  de  un  paquete  binario  a 
partir  de  otro  con  el  código  fuente: 


$  rpmbuild  --rebuild  -v  gaim-1 . 0 . 1-0 . src . rpm 
Installing  gaim-1 . 0 . 1-0 . src . rpm 
Executing (%prep) :  [...] 

+  tar  -xvvf  -  [ . . . ] 

Executing (%build) :  [ . . . ] 

+  ./configure 
checking  for  [ . . . ] 

+  make  [ . . . ] 

Executing (%doc) :  [...] 

Wrote :  /usr / src/RPM/RPMS/ i5 8  6 /gaim-1 .0.1-0.Í586. rpm 
Wrote :  /usr/ src/RPM/RPMS/ i58  6/gaim-devel-l .0.1-0.Í586. rpm 
Executing (%clean) :  [ . . . ] 
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Aquí  vemos  los  pasos  que  da  rpmbuild  para  crear  el  paquete  final: 

1 )  Sección  %prep  del  fichero  .spec.  En  esta  sección  se  suele  descom¬ 
primir  el  código  fuente  y  pasar  todos  los  parches  que  pudiesen  ser 
necesarios. 

2)  Sección  %build  del  fichero  .spec.  Aquí  es  donde  se  compila  el 
paquete.  En  caso  de  tener  scripts  de  configuración,  éstos  se  ejecutan. 

3)  Sección  %install  del  fichero  .spec.  Se  instala  el  programa  com¬ 
pilado  en  un  directorio  temporal. 

4)  Sección  %doc  del  fichero  .spec.  Se  instala  la  documentación  co¬ 
rrespondiente. 

5)  Se  empaqueta  la  instalación  temporal  en  un  fichero  .rpm. 

6)  Se  crea  un  paquete  adicional  con  los  encabezados  (.h)  de  los  fi¬ 
cheros  de  código  fuente  para  permitir  el  desarrollo  y/o  compilación 
de  paquetes  basados  en  éste. 

7)  Sección  %clean  del  fichero  .spec.  Para  terminar,  se  eliminan  to¬ 
dos  los  ficheros  temporales  (incluido  el  código  fuente  instalado). 

No  es  obligatorio  efectuar  estos  pasos  todos  seguidos  de  una  vez. 
Para  ello,  rpmbuild  ofrece  las  opciones  -bp,  -be  y  -bi  que  corres¬ 
ponden  a  parar  la  ejecución  tras  las  fases  de  %prep,  %build  e 
%install  respectivamente. 

De  esta  forma  se  puede  continuar  la  instalación  tras  realizar  las 
oportunas  modificaciones  en  cada  fase.  Por  ejemplo,  se  puede  eje¬ 
cutar  sólo  %prep,  pasar  algún  parche  adicional  al  código  fuente,  y 
seguir  la  instalación  desde  ahí. 

Para  la  creación  de  paquetes,  rpmbuild  ofrece  las  opciones  -bs,  -bb  y 
-ba,  con  las  que  se  pueden  crear  paquetes  de  código  fuente,  binarios, 
o  de  ambos  tipos  respectivamente. 
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Como  paso  adicional,  al  igual  que  antes  hemos  podido  comprobar 
la  firma  de  los  paquetes,  ahora  la  podemos  crear  por  medio  de  la 
opción  --addsign: 


$  rpm  --addsign  -v  XllR6-contrib-6 . 7 . 0-4 . 2 . lOlmdk. i586 . rpm 
Enter  pass  phrase: 

Pass  phrase  is  good. 

XllR6-contrib-6 . 7 . 0-4 . 2 . lOlmdk. i586 . rpm: 


La  configuración  de  la  clave  que  hay  que  utilizar  se  puede  especificar 

en  / etc  / rpm/macros  o  en  ~ /  .  rpmmacros  con  la  sintaxis: 

%_signature  gpg 
%_gpg_path  / etc /rpm/ . gpg 

%_gpg_name  Nombre  Usuario  <nombre@dominio . com> 

%_gpgbin  /usr/bin/gpg 


Cogiendo  primero  la  clave  del  anillo  del  usuario  en  curso  y  posterior¬ 
mente  del  especificado  en  %_gpg_path. 

Se  puede  comprobar  su  validez  otra  vez  con  -checksig: 

$  rpm  --checksig  -v  XllR6-contrib-6 . 7 . 0-4 . 2 . lOlmdk. i586 . rpm 
XllR6-contrib-6 . 7 . 0-4 . 2 . lOlmdk. i586 . rpm: 

Header  V3  DSA  signature:  NOKEY,  key  ID  0f219629 

Header  SHA1  digest:  OK  (caa530fe83f24cbdeefbfbfb0db53f21cd860e07) 

MD5  digest:  OK  (023c21cf 6ef0f 6f0841ffa0b9010ac43) 

V3  DSA  signature:  NOKEY,  key  ID  0f219629 

Donde  se  observa  que  la  nueva  firma  ha  sustituido  a  la  anterior.  Esto 
es,  un  paquete  sólo  puede  estar  firmado  con  una  única  firma  al  mis¬ 
mo  tiempo. 


6.4.8.  Para  finalizar  con  RPM 

La  configuración  de  RPM  se  define  en  el  fichero  /etc/ rpm/macros 
y  en  el  ~ ¡  .  rpmmacros  de  cada  usuario  como  modificaciones  a  las 
macros  por  defecto. 

Para  consultar  las  macros  y  demás  configuración  efectivas  en  cada 
momento  se  puede  usar  la  opción  — showrc: 
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Software  libre 


$  rpm  --showrc 
ARCHITECTURE  AND  OS: 


build  arch  : 
compatible  build  archs : 
build  os  : 
compatible  build  os's  : 
install  arch  : 
install  os  : 
compatible  archs  : 
compatible  os's  : 


i58  6 

athlon  i686  i586  i486  i386  noarch 

Linux 

Linux 

athlon 

Linux 

athlon  i686  i586  i486  i386  noarch 
Linux 


RPMRC  VALUES: 

macrofiles  :  /usr/lib/rpm/macros : /usr/lib/rpm/athlon-linux/macros : /etc/rpm/macros . specspo : /etc/ 

rpm/macros .prelin 

k: /etc/rpm/macros . solve : /etc/rpm/macros . up2date : /etc/rpm/macros : /etc/rpm/athlon-linux/macros : /etc/ 

rpm/macros . jpackage : ~/ . rp 

mmacros 

optflags  :  -02  -fomit-f rame-pointer  -pipe  -march=athlon  % { debugcf lags } 


Features  supported  by  rpmlib: 

rpmlib (VersionedDependencies )  =  3. 0.3-1 

PreReq:,  Provides:,  and  Obsoletes :  dependencies  support  versions. 


-14:  GNUconf igure (MCs : ) 

CFLAGS=" $ { CFLAGS : -%optf lags } "  ;  export  CFLAGS ; 

LDFLAGS="$ {LDFLAGS : -%{-s : -s} } "  ;  export  LDFLAGS ; 

% { -C :_mydir=" 'pwd' " ;  %{-M:  %{ _ mkdir}  -p  %{-C*};}  cd  %{-C*}} 

dirs="'find  ${_mydir}  -ñame  configure. in  -print'";  export  dirs; 
for  coin  in  'echo  ${dirs}' 
do 

dr='dirname  ${coin}'; 
if  test  -f  $ {dr} /NO-AUTO-GEN;  then 

else 


active  321  empty  () 

Para  modificar  cualquiera  de  estas  macros  y  opciones  de  configura¬ 
ción,  es  suficiente  con  añadirlas  a  uno  de  los  ficheros  de  configuración 
vigentes  durante  la  ejecución  de  rpm. 

En  raras  ocasiones  (por  ejemplo,  tras  un  uso  "creativo"  de  rpm)  es 
posible  que  la  base  de  datos  contenga  inconsistencias  en  relación 
con  los  datos  de  los  paquetes  instalados.  Un  síntoma  puede  ser,  por 
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ejemplo,  que  al  intentar  listar  los  paquetes  instalados  con  rpm  -qa, 
se  muestren  una  serie  de  éstos  pero,  al  llegar  a  un  punto,  rpm  no 
pueda  continuar. 

Para  solucionarlo,  suele  ser  suficiente  re-crear  los  índices  de  la  base  de 
datos  a  partir  del  listado  de  paquetes  instalados  con  la  opción 

--rebuilddb: 

$  rpm  --rebuilddb 


Si  con  esto  no  fuese  suficiente,  o  directamente  se  quisiese  limpiar  la 
base  de  datos  de  rpm,  se  puede  recurrir  a  la  opción  --initdb: 


$  rpm  --initdb 


Otra  forma  de  obtener  datos  de  los  paquetes  instalados  es  por  me¬ 
dio  de  la  opción  --queryformat,  que  permite  especificar  los  datos 
concretos  que  nos  interesan  de  cada  paquete: 

$  rpm  -q  --queryformat  "%{NAME}  % { OS } \n% { LICENSE } \n"  gaim 

gaim  linux 

GPL 

Una  lista  de  todos  los  campos  que  se  pueden  usar  en  la  cadena  de 
formato  se  obtiene  con  la  opción  -querytags: 

$  rpm  -querytags 
ARCH 

ARCHIVES IZE 

[.  .  .] 

VERSION 

XPM 


6.5.  DEB 


El  formato  de  paquetes  utilizado  por  Debian  y  distribuciones  deriva¬ 
das  es  el  .deb.  Se  diferencia  de  los  .rpm,  aparte  de  en  el  formato  del 
paquete  en  sí,  en  ciertas  opciones  de  dependencias  y  en  que  está 
pensado  directamente  para  ser  utilizado  por  gestores  de  paquetes 
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como  apt.  Esta  última  diferencia  va  perdiendo  importancia  según  se 
mejoran  los  gestores  de  paquetes  para  rpm. 


6.5.1 .  APT,  DPKG.  DSELECT,  APTITUDE,  CONSOLE  APT,  etc. 

Los  paquetes  en  sí  son  los  .deb.  Aunque  el  formato  puede  variar  en¬ 
tre  distribuciones  [consultar  deb  (5)  ],  son  ficheros  que  contienen  un 
fichero  .tar.gz  con  el  contenido  en  sí  y  unos  metadatos  de  control. 

La  gestión  de  estos  paquetes  se  realiza  por  medio  del  software  dpkg, 
que  mantiene  una  base  de  datos  de  metadatos  de  los  paquetes  ins¬ 
talados  y  se  encarga  de  instalarlos  y  desinstalarlos. 

Mientras  tanto,  la  gestión  automatizada  de  dependencias  se  realiza 
por  medio  de  la  utilidad  apt,  que  permite  autodetectar,  descargar  e 
instalar  automáticamente  todos  los  elementos  necesarios  para  el  co¬ 
rrecto  funcionamiento  de  un  programa. 

Tanto  dpkg  como  apt  tienen  sus  correspondientes  front-ends  llama¬ 
dos  dselect  y  aptitude  respectivamente.  Aunque  directamente  dpkg  y 
apt  ofrecen  mayor  flexibilidad  y  número  de  opciones,  el  manejo  de 
listas  de  paquetes  se  hace  más  fácil  al  poder  navegar  a  través  de  es¬ 
tas  listas  y  operar  sobre  cada  paquete  en  concreto. 

Existen  otros  programas  capaces  de  realizar  estas  tareas,  incluso,  grá¬ 
ficos,  como  Synaptic,  aunque  no  son  oficiales  del  proyecto  Debian. 


6.5.2.  APT,  comandos  básicos 

Apt  se  compone  de  una  serie  de  utilidades  encargadas  por  un  lado 
de  la  gestión  de  dependencias  y  por  el  otro  de  los  repositorios  y  lis¬ 
tados  de  paquetes. 

Estas  utilidades  son: 

apt-get:  encargado  de  descargar/instalar  los  paquetes, 
apt-cache:  ofrece  un  acceso  a  los  listados  de  paquetes. 
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apt-cdrom:  permite  añadir  repositorios  de  paquetes  en  CD  o  DVD. 
apt-ftparchive:  permite  añadir  repositorios  accesibles  por  ftp. 


Aparte  de  estas  utilidades,  la  configuración  de  repositorios  se  alma¬ 
cena  en: 


/ etc/apt/ sources. list 


descrita  en  la  entrada  de  manual  source  .  list  (5) . 

Antes  de  nada  hay  que  obtener  una  lista  de  las  últimas  versiones  de 
los  paquetes  disponibles  en  los  distintos  repositorios  que  tengamos 
configurados.  Estos  repositorios  son  conjuntos  de  paquetes  almace¬ 
nados  en  lugares  accesibles  por  red,  cuya  estructura  es  reconocible 
por  el  software  instalador. 


#  apt-get  update 

Get : 1  http://non-us.debian.org  stable/non-US/main  Packages  [44.5kB] 

Get : 2  http://http.us.debian.org  stable/main  Packages  [1773kB] 

[...] 

Get: 17  http://security.debian.org  stable/updates/non-f ree  Packages  [1221B] 
Get:18  http://security.debian.org  stable/updates/non-f ree  Release  [114B] 
Fetched  2151kB  in  31s  (67.8kB/s) 

Reading  Package  Lists...  Done 
Building  Dependency  Tree...  Done 


Una  vez  actualizada  la  base  de  datos,  podemos  proceder  a  instalar 
algún  paquete  que  nos  interese  con  apt-get  install: 

#  apt-get  install  aptitude 
Reading  Package  Lists...  Done 
Building  Dependency  Tree...  Done 


...  tras  analizar  la  base  de  datos  de  dependencias,  es  posible  que  se 
necesiten  paquetes  adicionales  para  que  el  software  que  nos  interesa 
funcione  correctamente: 


The  following  extra  packages  will  be  installed: 
libsigc++0 
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The  following  NEW  packages  will  be  installed: 
aptitude  libsigc++0 

0  packages  upgraded,  2  newly  installed,  0  to  remove  and  19  not  upgraded. 
Need  to  get  939kB  of  archives.  After  unpacking  3310kB  will  be  used. 
Do  you  want  to  continué?  [Y/n] 

...  si  no  tenemos  nada  en  contra  de  la  detección  realizada  por  apt, 
el  siguiente  paso  es  descargar  los  paquetes  desde  el  repositorio  más 
adecuado: 


Get:l  http://http.us.debian.org  stable/main  libsigc++0  1.0. 4-3  [28.0kB] 
Get:2  http://http.us.debian.org  stable/main  aptitude  0.2.11.1-4  [910kB] 
Fetched  939kB  in  14s  (64.5kB/s) 

...  y  posteriormente  instalarlos: 


Selecting  previously  deselected  package  libsigc++0. 

(Reading  database  ...  5275  files  and  directories  currently  installed.) 
Unpacking  libsigc++0  (from  . . . /Iibsigc++0_1 . 0 . 4-3_i38 6 . deb)  ... 
Selecting  previously  deselected  package  aptitude. 

Unpacking  aptitude  (from  . . . /aptitude_0 . 2 . 11 . l-4_i386 . deb)  ... 
Setting  up  libsigc++0  (1.0. 4-3)  ... 

Setting  up  aptitude  (0.2.11.1-4)  ... 


Además  de  instalar,  también  podemos  actualizar  todos  los  paquetes 
a  las  últimas  versiones  disponibles  en  los  repositorios  con  apt-get 
upgrade: 

#  apt-get  upgrade 

Reading  Package  Lists...  Done 

Building  Dependency  Tree...  Done 

18  packages  upgraded,  0  newly  installed,  0  to  remove  and  0  not  upgraded. 
Need  to  get  6778kB  of  archives.  After  unpacking  419kB  will  be  used. 
Do  you  want  to  continué?  [Y/n] 


...  si  aceptamos  la  propuesta  de  actualización  de  apt-get,  pasará 
a  descargar  los  paquetes  necesarios: 


Get:l  http://security.debian.org  stable/updates/main  gzip  1 . 3 . 2-3woody3  [62.1kB] 
Get : 2  http://http.us.debian.org  stable/main  bsdutils  l:2.11n-7  [39.5kB] 
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...  y  a  instalarlos: 


(Reading  database  ...  6842  files  and  directories  currently  installed.) 

Preparing  to  replace  bsdutils  l:2.11n-4  (using  . . . /bsdutils_l%3a2 . Iln-7_i386 . deb)  .. 
Unpacking  replacement  bsdutils  . .  . 

Setting  up  bsdutils  (2.11n-7)  ... 


De  esta  forma  podemos  mantener  siempre  actualizados  los  progra¬ 
mas  en  la  última  versión  disponible  en  los  repositorios  elegidos. 

Una  forma  más  cómoda  de  gestionar  los  paquetes  es  con  el  fronf- 
end  oficial  de  apt  llamado  aptitude: 


Figura  1 


Actions  Undo  Options  Uieus  Help 

flO:  flenu  ?:  Help  q:  Quit  u:  Update  g:  Doun load/ Insta  1 1  Pkgs 
aptitude  9.2.11.1 Uill  use  423kB  of  disk  spa  OL  Size:  7Z 


-  Installed  Packages 

-  Not  Installed  Packages 

-  Uirtual  Packages 

-  Tasks 


A  neuer  uersion  of  these  packages  ís  auailable. 


Aquí  encontraremos  una  lista  de  los  paquetes  instalados  e  instalables 
de  la  que  podremos  elegir  cualquiera  de  ellos  para  instalar  nuevos  y 
actualizar  o  desinstalar  los  ya  presentes. 


Figura  2 


ñctions  Undo  Options  Uieus  Help  _ 

flO :  Henu  ?:  Help  q:  Quit  u:  Update  g:  Doun load/ Insta 1 1  Pkgs 
aptitude  0.2.11.1  Uill  use  423kB  of  disk  spa  DL  Size:  72 

— \  Upgradable  Packages _ 


base  -  The  Debían  base  systcn 


-  doc  -  Docunentation  and  specialized  prograns  for  uieuing  doc 

-  editors  -  Text  editors  and  uord  processors 

-  libs  -  Collections  of  software  routines 

-  nail  -  Prograns  to  urite,  send,  and  route  enail  nessages 

-  net  -  Prograns  to  connect  to  and  prouide  uarious  seruices 

Packages  in  the  'base*  section  are  part  of  the  initial  systen 
instal la t ion. 
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Los  paquetes  aparecen  ordenados  por  temas  para  facilitar  la  locali¬ 
zación  de  aquel  que  nos  interese. 


Dentro  de  la  lista  de  paquetes,  al  posicionarnos  sobre  cualquiera  de 
ellos  se  muestra  la  información  pertinente  en  la  mitad  inferior  de  la 
pantalla: 


Figura  3 


Actions  lindo  Options  Uieus  Help  _ 

flO:  Menú  ?:  Help  q:  Quit  u:  Update  g:  Doun load/ Insta  1 1  Pkgs 
aptitude  0.2.11.1  U i  1 1  use  423kB  of  disk  spa  DL  Size:  72 

— S  Upgradable  Packages 

— S  base  -  The  Debian  base  systen 
— S  nain  -  The  nain  Debian  archive 

Qu  debianutils  1.16  1.16.2wood 


Hiscel laneous  Utilities  specific  to  Debian. 

Debianutils  ineludes  instal lkernel  nkboot  nktenp  readlink 
run-parts  sauelog 

sensible-ed itor  sensible-pager  tenpfile  uhich. 


Al  seleccionar  un  paquete,  se  presenta  una  descripción  y  una  serie 
de  metadatos  relacionados,  incluidas  las  dependencias  y  sugeren¬ 
cias  para  su  instalación. 


Figura  4 


Actions  lindo  Options  Uieus  Help 

flO:  Henu  ?:  Help  q:  Quit  u:  Update  g:  Doun load/ Insta  1 1  Pkgs 
aptitude  0.2.11.1  Uill  use  423kB  of  disk  spa  DL  Size:  72 

debianutils  -  Hiscel laneous  Utilities  specific  to  Debian. 
Debianutils  ineludes  instal lkernel  nkboot  nktenp  readlink  run-par 
sensible-editor  sensible-pager  tenpfile  uhich. 

Essential:  yes 
Priority:  required 
Section:  base 

Maintainer:  Guy  Haor  <naorPdebian.org> 

Conpressed  size:  32. 9k 
Unconpressed  size:  184k 
Source  Package:  debianutils 
— \  PreDepends 
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Del  mismo  modo  se  listan  los  paquetes  virtuales.  Esto  es,  paquetes 
"de  funcionalidad"  agrupando  distintos  paquetes  equivalentes  entre 


sí  que  ofrezcan  una  funcionalidad  determinada  al  sistema  (servidor 
DNS,  servidor  HTTP,  etc): 


Figura  5 


Actions  lindo  Options  Uieus  Help 

flO:  Henu  ?:  Help  q:  Quit  u:  Update  g:  Doun load/ Insta  1 1  Pkgs 
aptitude  0.2.11.1  Uill  use  423kB  of  disk  spa  DL  Size:  72 

-  Uirtual  Packages _ 


h\  Tasks 


-  Deuelopnent 

-  End-user 

-  Localization 

-  Hiscel laneous 

-  Seruers 

Tasks  are  groups  of  packages  uhich  prouide  an  easy  uay  to  select  a 
predefined  set  of  packages  for  a  particular  purpose. 


Figura  6 


Actions  lindo  Options  Uieus  Help 

flO:  Henu  ?:  Help  q:  Quit  u:  Update  g:  Doun load/ Insta  11  Pkgs 


aptitude  0.2.11.1 

Uill  use  423kB  of  disk  spa 

DL  Size:  72 

— \  Seruers 
— S  DHS  seruer 

I  bindS 

<none> 

1:9. 2. 1-2. 

p  bind9-doc 

<none> 

1:9. 2. 1-2. 

p  dlint 

<none> 

1.4. 0-4 

p  dnsutils 

<none> 

1:9. 2. 1-2. 

p  luresd 

<none> 

1:9. 2. 1-2. 

Internet  Donain  Nane  Seruer 

The  Berkeley  Internet  Hane  Donain  CBIHD)  inplenents  an  Internet 
donain 

nane  seruer.  BIHD  is  the  nost  uidely-used  nane  seruer  software  on 
the 

Internet,  and  is  supported  by  the  Internet  Software  Consortiun, 
wuu. isc.org. 


Para  facilitar  las  tareas  de  mantenimiento,  aptitude  presenta  un 
menú  (accesible  con  FlO),  desde  el  que  se  pueden  realizar  distintas 
tareas  de  administración,  incluido  algún  entretenimiento  alternativo 
como  mirar  la  barra  de  progreso  en  instalaciones  largas. 
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También  desde  este  menú  se  pueden  configurar  varios  aspectos  del 
comportamiento  de  apt: 


Figura  8 


fictions  lindo  Options  Uieus  Help 

flO:  Henu  ?:  Help  q:  Quit  u:  Update  g:  Dounload/Instal 1  Pkgs 
aptitude  0.2.11.1  Uill  use  423kB  of  disk  spa  DL  Size:  72 

-  Upgradable  Packages 

- Insta  11 ed  Packages _ 


[£jl  Autonatical  ly  reso  lúe  dependencies  of  a  package  ulien  it  is  s 
[XI  ñutonatical ly  fix  broken  packages  before  installing  or  renou 
[XI  Install  Recomnended  packages  autonatical ly 
[X]  Install  Suggested  packages  autonatical ly 
[XI  Renoue  unused  packages  autonatical ly 


6.5.3.  DPKG 

El  programa  encargado  de  la  gestión  de  la  base  de  datos  y  de  la  ins¬ 
talación  de  paquetes  es  dpkg. 

Para  la  funcionalidad  de  instalación,  normalmente  se  llamará  desde 
apt,  dada  la  comodidad  que  ofrece  la  detección  automática  de  de¬ 
pendencias. 
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Sin  embargo,  dpkg  ofrece  otras  funcionalidades  adicionales  relacio¬ 
nadas  con  la  base  de  datos  de  paquetes  instalados. 


En  la  base  de  datos  un  paquete  puede  estar  en  uno  de  los  siguientes 
estados: 


not-installed:  sin  instalar  en  el  sistema. 

half-installed:  a  medio  instalar  (la  instalación  posiblemente  se 
ha  interrumpido). 

unpacked:  copiado  al  sistema  pero  sin  configurar. 

half-conf igured:  a  medio  configurar  (se  ha  comenzado  a  confi¬ 
gurar  pero  sin  terminar). 

installed:  instalado  correctamente. 

conf ig-f iles:  desinstalado  pero  sin  borrar  los  ficheros  de  confi¬ 
guración. 

Normalmente  todos  los  paquetes  son  gestionados  por  dpkg,  excepto 
los  marcados  como  "hold". 

Para  ver  un  listado  de  todos  los  paquetes  instalados,  ¡unto  con  sus 
estados  y  versiones,  podemos  utilizar  la  opción  -1  de  dpkg: 

$  dpkg  -1 

Desired=Unknown/ Install/Remove/Purge/Hold 

I  Estado=No/ Ins talado /Conf ig-f i les /Unpacked/ Failed- conf ig/ Half-installed 
1/  Err?= (none) /Hold/Reinst-required/X=both-problems  (Status, Err:  mayúsc . =malo) 
I | /  Nombre  Versión  Descripción 


+++-=: 


ii  adduser 


3.47 


Add  and  remove  users  and  groups 


ii  alien 


8.05-3 


install  non-native  packages  with  dpkg 


i  i  apt 


0.5.4 


Advanced  front-end  for  dpkg 


ii  apt-utils 


0.5.4 


APT  utility  programs 


ii  aptitude 


0.2.11.1-4 


curses-based  apt  frontend 


La  primera  columna  indica  el  estado  en  el  que  se  desearía  tener  el 
paquete,  mientras  que  la  segunda  indica  el  estado  actual  en  el  siste¬ 
ma.  En  la  tercera  columna  se  indican  los  errores  de  instalación,  ésta 
se  encuentra  vacía  al  no  existir  errores. 
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Aunque  es  recomendable  hacerlo  desde  apt,  también  se  pueden  ins¬ 
talar  paquetes  por  separado  desde  dpkg  con  la  opción  -i: 

$  dpkg  -i  /var/cache/apt/archives/alien_8 . 05_all . deb 
Seleccionando  el  paquete  alien  previamente  no  seleccionado. 
(Leyendo  la  base  de  datos  . . . 

7225  ficheros  y  directorios  instalados  actualmente.) 
Desempaquetando  alien  (de  . . . /archives/alien_8 . 05_all . deb)  ... 
Configurando  alien  (8.05)  ... 

Así  como  desinstalarlos  con  la  opción  -r: 

$  dpkg  -r  alien 

(Leyendo  la  base  de  datos  . . . 

7258  ficheros  y  directorios  instalados  actualmente.) 

Desinstalando  alien  . . . 


Un  paso  intermedio  de  la  instalación  consistente  en  sólo  la  copia  de 
los  ficheros  al  sistema  se  puede  conseguir  con  la  opción  --unpack: 


$  dpkg  --unpack  /var/cache/apt/archives/alien_8 . 05_all . deb 
Seleccionando  el  paquete  alien  previamente  no  seleccionado. 
(Leyendo  la  base  de  datos  . . . 

7225  ficheros  y  directorios  instalados  actualmente.) 
Desempaquetando  alien  (de  . . . /archives/alien_8 . 05_all . deb)  ... 


Para  configurarlo  más  tarde  con  la  opción  --configure: 


$  dpkg  --configure  alien 
Configurando  alien  (8.05)  ... 

Los  Scripts  de  configuración  de  los  paquetes  tienen  otra  aplicación  in¬ 
teresante.  Aparte  de  permitir  la  configuración  interactiva  en  el  mo¬ 
mento  de  la  instalación  de  cada  paquete,  esto  añade  interesantes 
posibilidades  de  configuración  al  poder  "reconfigurar"  un  paquete 
ya  instalado: 

$  dpkg-reconf igure  locales 


Por  ejemplo,  con  el  anterior  comando  podemos  cambiar  la  configu¬ 
ración  de  idioma  instalada  en  el  sistema  sin  tener  que  preocuparnos 
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de  conocer  los  ficheros  exactos  de  configuración  ni  la  sintaxis  de  los 
mismos. 


6.5.4.  Creación  de  paquetes  deb  v  gestión  de  parches 

Una  parte  de  dpkg  es  la  gestión  de  paquetes  .deb,  que  se  realiza  por 
medio  de  dpkg-deb  (se  puede  llamar  directamente  como  dpkg). 

Para  listar  los  ficheros  que  contiene  un  paquete,  está  la  opción 

-c  (  — contents): 


$  dpkg  -c  alien_8.05-2 
drwxr-xr-x  root/root 
drwxr-xr-x  root/root 
drwxr-xr-x  root/root 
-rwxr-xr-x  root/root 
drwxr-xr-x  root/root 
drwxr-xr-x  root/root 
drwxr-xr-x  root/root 


.  deb 


0 

2004-11-17 

18:03:37 

0 

2004-11-17 

18:03:33 

0 

2004-11-17 

18:03:33 

13482 

2002-04-01 

18:37:26 

0 

2004-11-17 

18:03:34 

0 

2004-11-17 

18:03:33 

0 

2004-11-17 

18:03:33 

./ 

. / usr/ 

. /usr/bin/ 

. /usr/bin/alien 
. /usr/share/ 

. /usr/ share/ alien/ 

. /usr/ share/ alien/patches/ 


Una  información  general  sobre  el  paquete  se  obtiene  con  -I  (--info): 


$  dpkg  -I  alien_8 . 05-2_all . deb  |  less 
paquete  debian  nuevo,  versión  2.0. 

tamaño  112716  bytes :  archivo  de  control=  1511  bytes . 
518  bytes,  19  lineas  control 

27  lineas 
9  lineas 
7  lineas 


md5sums 

postinst 

prerm 


1989  bytes, 

249  bytes, 

192  bytes, 

Package:  alien 
Versión:  8.05-2 
Section:  alien 
Priority:  extra 
Architecture :  all 
Installed-Size :  251 
Maintainer:  root  <root@> 

Description:  install  non-native  packages  with  dpkg 


# ! /bin/sh 
# ! /bin/sh 


Alien  allows  you  to  convert  LSB,  Red  Hat,  Stampede  and  Slackware 
Packages 

into  Debian  packages,  which  can  be  installed  with  dpkg. 
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Para  extraer  únicamente  los  metadatos,  tenemos  la  opción  -f 

(--field) : 

$  dpkg  -f  alien_8.05-2_all.deb  |  less 

Package:  alien 

Versión:  8.05-2 

Section:  alien 

Priority:  extra 

Architecture :  all 

Installed-Size :  251 

Maintainer:  root  <root@> 

Description:  install  non-native  packages  with  dpkg 

Alien  allows  you  to  convert  LSB,  Red  Hat,  Stampede  and  Slackware 
Packages 

into  Debian  packages,  which  can  be  installed  with  dpkg. 


Si  necesitamos  extraer  los  ficheros  del  paquete  en  un  directorio  que 
no  sea  el  de  instalación,  podemos  usar  la  opción  -x  (— extract). 
Si  deseamos  ver  cada  fichero  según  está  siendo  extraído  ("verbose"), 
usaremos  -X  (— vextract): 

$  mkdir  /tmp/alienl 

$  dpkg  -x  alien_8.05-2_all.deb  /tmp/alienl/ 

./ 

. /usr / 

. /usr/bin/ 

. /usr/bin/alien 
. /usr/share/ 

. /usr/ share/ alien/ 

. /usr/ share/alien/patches/ 

. /usr/share/alien/patches/motif-devel_2 . 1.10-7. di ff.gz 
. /usr/share/alien/patches/motif_2 .1.10-7. di ff.gz 


Para  extraer  únicamente  los  datos  de  control  del  paquete  sin  necesi¬ 
dad  de  extraer  todos  los  ficheros,  podemos  usar  -e  (--control): 

$  mkdir  /tmp/alienl/DEBIAN 

$  dpkg  -e  alien_8.05-2_all.deb  /tmp/alienl/DEBIAN 
$  ls  -1  /tmp/alienl/DEBIAN 
total  5 


-rw-r— r— 

1 

root 

root 

518 

nov 

17 

18:03 

control 

-rw-r— r— 

1 

root 

root 

1989 

nov 

17 

18:03 

md5sums 

-rwxr-xr-x 

1 

root 

root 

249 

nov 

17 

18:03 

postinst 

-rwxr-xr-x 

1 

root 

root 

192 

nov 

17 

18:03 

prerm 
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Asimismo,  con  -b  (-- bui Id)  podemos  construir  un  paquete  .deb  a  par¬ 
tir  de  un  directorio  que  contenga  los  datos  y  un  directorio  adicional 
DEBIAN  con  los  metadatos  y  Scripts  de  control. 

Con  esta  opción  se  puede  reconstruir  un  paquete  previamente  extraí¬ 
do  con  -x  y  -e: 

$  dpkg  -b  /tmp/alienl 

dpkg-deb:  construyendo  el  paquete  'alien'  en  ' /tmp/alienl . deb ' . 

$  ls  -1  /tmp/alienl . deb 

-rw-r— r—  1  root  root  112722  nov  17  18:03  /tmp/alienl . deb 


Para  crear  un  paquete  .deb,  lo  único  que  hace  falta  es  copiar  en  un 
directorio  los  ficheros  que  se  quieran  incluir  en  una  estructura  de  di¬ 
rectorios  relativa  al  directorio  raíz  (como  si  fuese  un  chroot)  y  añadir 
un  directorio  DEBIAN  en  el  que  se  incluirá  un  fichero  de  control  con 
los  datos  relativos  al  paquete  con  las  siguientes  líneas: 

Package:  nombre  del  paquete. 

Versión:  número  de  versión. 

Section:  sección  temática  en  la  que  irá  incluido  (p.  ej.  en  dselect). 

Architecture  :  plataforma  sobre  la  que  funcionará  el  paquete. 

Depends  :  lista  de  paquetes  de  los  que  depende.  Cada  paquete  puede 
ir  acompañado  de  un  número  de  versión  entre  paréntesis  precedido  de 
"<<"  (menor  que),  "<="  (menor  o  igual),  "="  (exactamente  la  versión 
especificada),  ">="  (mayor  o  igual),  ">>"  (sólo  mayor  que). 

Enhances  :  especifica  que  la  funcionalidad  de  determinado(s)  pa- 
quete(s)  será  mejorada  si  se  instala  éste  (por  ejemplo,  en  caso  de  que 
sea  un  paquete  de  documentación). 

Pre-Depends:  especifica  paquetes  que  deben  estar  ya  instalados 
obligatoriamente  antes  de  instalar  este  paquete  (no  permite  instala¬ 
ciones  de  "más  de  un  paquete"  en  orden  no  definido). 
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Recommends :  especifica  paquetes  relacionados  que  comúnmente 
son  instalados  con  este  paquete. 

Suggests  :  paquetes  que  tienen  alguna  relación  con  éste,  pero  no 
tienen  por  qué  ser  instalados  para  un  funcionamiento  normal. 

Installed-Size :  define  el  espacio  que  ocupará  el  paquete  una 
vez  instalado. 

Maintainer :  nombre  y  dirección  de  correo  del  encargado  del  pa¬ 
quete  en  formato  "Nombre  <correo@dominio>". 

Conflicts:  paquetes  que  no  pueden  estar  instalados  al  mismo 
tiempo  que  éste  para  su  correcto  funcionamiento. 

Replaces:  este  paquete  sustituye  a  determinados  otros  paquetes 
(que  no  podrán  estar  instalados  al  mismo  tiempo). 

Description:  un  texto  descriptivo  del  paquete. 

Además  de  este  fichero  de  control,  se  deben  especificar  dos  Scripts  (shell) 
para  ser  ejecutados  en  el  momento  de  la  instalación  (postinst)  y  de 
la  desinstalación  (prerm). 


6.5.5.  Alien  (convertir  paquetes  DEB,  RPM  v  TGZ) 

Para  paliar  el  problema  de  distribución  que  se  presenta  al  haber  di¬ 
ferentes  formatos  de  paquetes  entre  las  distintas  distribuciones,  se 
puede  recurrir  al  programa  alien  que  permitirá  convertir  paquetes  ya 
creados  entre  los  formatos  rpm,  deb,  tgz  y  algunos  más. 


6.5.6.  Comandos  básicos  Alien 

La  forma  básica  de  uso  es  con  las  opciones  --to-deb  y  --to-rpm: 

$  alien  --to-rpm  alien_8 . 05_all . deb 
alien-8 . 05-2 . noarch . rpm  generated 


246 


Igualmente,  si  deseamos  pasar  de  deb  a  rpm: 


$  alien  --to-deb  alien-8 . 05-2 . noarch . rpm 
alien_8 . 05-3_all . deb  generated 


También  podemos  instalar  directamente  el  paquete  convertido  (p.  e¡. 
instalar  un  paquete  .  rpm  en  un  sistema  basado  en  .  deb): 

$  alien  --to-deb  -i  alien-8 . 05-2 . noarch . rpm 
(Leyendo  la  base  de  datos  . . . 

7257  ficheros  y  directorios  instalados  actualmente.) 

Preparando  para  reemplazar  alien  8.05  (usando  alien_8 . 05-_all . deb)  ... 
Desempaquetando  el  reemplazo  de  alien  . . . 

Configurando  alien  (8.05-3)  ... 

Para  distribuir  paquetes  convertidos  de  esta  forma,  hay  que  tener  en 
cuenta  que  alien,  por  defecto,  aumenta  en  uno  el  número  menor  de 
versión  (en  el  anterior  ejemplo  de  8.05-2  a  8.05-3).  Esto  se  puede 
evitar  especificando  la  opción  -k: 

$  alien  --to-deb  -k  alien-8 . 05-2 . noarch . rpm 
alien_8 . 05-2_all . deb  generated 


Si  lo  que  nos  interesa  es  poder  compilar  el  paquete  en  cuestión  en  la 
plataforma  deseada  pero  pudiendo  cambiar  antes  algo  en  él,  tene¬ 
mos  la  opción  -g  que  extraerá  el  contenido  en  un  directorio  temporal: 

$  alien  -g  alien-8 . 05-2 . noarch . rpm 

Directories  alien-8. 05  and  alien-8 . 05 . orig  prepared. 


En  este  caso,  dado  que  alien  por  defecto  exporta  al  formato  .deb, 
se  habrán  creado  dos  directorios  desde  los  que  se  podrá  crear  un  pa¬ 
quete  .  deb  y  un  paquete  .  rpm  respectivamente. 


6.6.  Conclusiones 


El  contenedor  tar  guarda  estructuras  completas  de  archivos  y  direc¬ 
torios  y  ¡unto  con  el  compresor  gzip  es  capaz  de  distribuir  software 
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de  forma  homogénea  pero  inconsistente,  es  decir,  su  instalación  es 
independiente  de  otros  paquetes  de  software  e  incluso  de  una  insta¬ 
lación  idéntica  anterior. 

rpm  y  deb  toman  todo  lo  bueno  de  los  anteriores  guardando  una 
consistencia  de  datos  y  versiones  necesaria  para  la  distribución  del 
software  por  Internet  y  las  instalaciones  desatendidas. 

La  evolución  de  estos  sistemas  consistentes  y  su  compatibilidad  de¬ 
terminará  el  o  los  sistemas  de  distribución  de  software  del  futuro. 

Lo  más  deseable:  un  front-end  independiente  del  sistema  de  distribu¬ 
ción  que  compatibilice  versiones  y  unifique  bases  de  datos,  pudiendo 
gestionar  de  manera  transparente  cualquiera  de  ellos.  La  comunidad 
está  en  ello. 
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7.  Sistemas  de  creación  de  documentación 


7.1 .  Introducción 

Este  capítulo  cubre  los  distintos  aspectos  relacionados  con  los  sistemas 
de  documentación  más  aceptados  dentro  del  mundo  del  software  libre 
y  de  fuente  abierta.  La  documentación  en  el  ámbito  de  software  juega 
un  papel  importantísimo  como  complemento  indispensable  de  los  pro¬ 
gramas  informáticos.  Se  plantean  las  diferentes  motivaciones  que 
llevan  a  tener  sistemas  de  documentación  libre  y  se  presentan  los  dis¬ 
tintos  tipos  de  licencias  con  los  que  la  documentación  es  distribuida. 
También  se  analizan  cada  uno  de  los  sistemas  de  documentación  en 
forma  particular  que  le  permiten  crear  documentos  básicos. 

En  particular  se  describe  desde  la  simple  documentación  de  una  pá¬ 
gina  de  manual,  pasando  por  documentación  de  desarrollo,  docu¬ 
mentación  de  breves  manuales,  hasta  la  posibilidad  de  escribir  libros 
completos;  todo  con  carácter  profesional  y  útil  para  obtener  coope¬ 
ración,  como  se  espera  en  el  mundo  del  software  libre. 


7.2.  Objetivos 

Una  vez  estudiado  este  capítulo,  el  lector  podrá  hacer  lo  siguiente: 


•  Crear  documentos  básicos  en  cada  uno  de  los  sistemas  planteados. 

•  Conocer  cada  uno  de  los  sistemas  de  documentación,  lo  que  le 
permitirá  poder  decidir  qué  sistema  utilizar  para  documentar  su 
software,  de  acuerdo  a  las  necesidades  del  caso. 

•  Crear  páginas  de  manual. 

•  Crear  documentos  cortos  (HowTo,  manuales,  etc.). 

•  Crear  libros  de  documentación  (manuales,  tratados,  etc.). 
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7.3.  Documentación  libre:  estándares 
y  automatización 

Un  sistema  o  software  pobremente  documentado  carece  de  valor 
aunque  haya  funcionado  bien  en  alguna  ocasión.  En  el  caso  de  pro¬ 
gramas  pequeños  y  poco  importantes  que  sólo  se  utilizan  durante  un 
corto  periodo  de  tiempo,  unos  cuantos  comentarios  en  el  código  po¬ 
drían  ser  suficientes.  No  obstante,  la  mayoría  de  los  programas  cuya 
única  documentación  es  el  código  no  tienen  aceptación  y  es  imposi¬ 
ble  mantenerlos.  Dedicar  un  poco  de  esfuerzo  a  la  documentación, 
incluso  dentro  de  los  límites  de  un  pequeño  proyecto,  constituye  una 
muy  buena  práctica. 

Aprender  a  documentar  software  es  una  tarea  complicada  y  exige  un 
criterio  de  ingeniería  maduro.  Documentar  escuetamente  es  un  error 
habitual,  pero  el  otro  extremo  puede  resultar  igual  de  perjudicial:  si 
escribe  documentaciones  extensas,  éstas  atosigarán  al  lector  y  cons¬ 
tituirán  una  carga  a  la  hora  de  mantenerlas.  Es  esencial  documentar 
sólo  los  asuntos  correctos.  La  documentación  no  sirve  de  ayuda  para 
nadie  si  su  extensión  desanima  a  la  gente  a  la  hora  de  leerla. 

Este  apartado  provee  al  lector  de  las  directrices  sobre  cómo  documen¬ 
tar,  principalmente  orientado  a  sistemas  de  software  libre,  es  decir,  do¬ 
cumentar  con  herramientas  libres  y  en  formatos  libres.  Asimismo,  le 
proporcionará  una  estructura  esquemática  de  tipos  de  documentos, 
quedando  a  su  criterio  la  utilización  de  estos  ejemplos. 


7.3.1.  La  documentación  del  software 

Una  parte  fundamental  del  software  es  la  documentación  que  lo 
acompaña.  La  documentación  es  una  pieza  tan  importante  de  un 
programa  que  en  ocasiones  éste  será  inútil  sin  ella. 

La  documentación  del  software  está  dividida  en  distintos  tipos  de 
acuerdo  a  lo  que  ella  documente,  y  generalmente  existe: 

•  Documentación  de  desarrollo: 

-  Análisis,  requisitos,  especificaciones 

-  Diagramas 
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-  Comentarios  en  códigos 

-  Documentación  de  pruebas,  etc. 

•  Documentación  de  programa: 

-  Ayuda  en  línea 

-  Página  de  manual  (man) 

•  Documentación  de  usuario: 

-  Manual  de  uso 

-  Libros  y  tutoriales 

-  Guías  de  enseñanza  o  autoaprendizaje 

Obviamente,  ésta  es  una  lista  reducida  de  las  posibilidades  de  docu¬ 
mentación  en  torno  a  un  software  determinado  y  la  documentación 
que  se  utilizará  dependerá  del  alcance  del  software  en  cuestión. 

Otra  característica  de  la  documentación  del  software  es  que  la  mis¬ 
ma  debe  acompañar  el  desarrollo  o  evolución  del  software  que  do¬ 
cumenta.  Es  decir,  de  la  misma  forma  que  el  software  avanza  y  se 
desarrolla,  la  documentación  debe  avanzar  y  desarrollarse  conjun¬ 
tamente,  de  manera  que  la  última  versión  de  la  documentación  re¬ 
fleje  las  características  y  el  estado  de  la  última  versión  del  software. 


7.3.2.  El  problema  de  documentar  software  libre 

Si  la  documentación  debe  evolucionar  ¡unto  al  software,  cuando  ha¬ 
blamos  de  software  libre  nos  encontramos  ante  el  problema  de  que 
estamos  documentando  un  software  potencialmente  realizado  por 
muchas  personas,  que  puede  ser  libremente  modificado  y  mejorado. 
Es  obvio,  entonces,  que  la  documentación  del  software  libre  debe  po¬ 
der  ser  libremente  modificada  y  mejorada  para  acompañar  la  evo¬ 
lución  del  software  libre.  De  hecho,  se  considera  que  software  libre 
sin  documentación  libre  no  es  un  software  libre,  ya  que  el  desarrollo 
libre  del  software  se  puede  ver  perjudicado  por  la  falta  de  un  acceso 
libre  a  su  documentación. 

Pensad,  por  ejemplo,  el  caso  en  que  tomarais  un  software  libre  y  le 
realizarais  algunas  mejoras;  si  la  documentación  no  fuese  libre,  en¬ 
tonces  no  podría  reflejar  su  mejora  en  el  mismo  documento,  lo  que 
significaría  un  problema  importante  para  el  desarrollo  o  al  menos 
para  la  difusión  y  aplicación  de  su  modificación. 
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7.3.3.  Licencias  libres  para  la  documentación 


Contenido 

complementario 


El  software  libre  es  aquel 
que  permite  al  usuario  co¬ 
piarlo,  mejorarlo  y  distri¬ 
buirlo  libremente. 

El  software  privativo  es 
aquel  que  carece  de  alguna 
o  de  la  mayoría  de  las  liber¬ 
tades  que  se  reciben  con  el 
software  libre. 


Nota 


http://www.gnu.org/ 

copyleft/fdl.html 

http://creative- 

commons.org/text/ 


Todo  software,  ya  sea  libre  o  privativo,  está  acompañado  por  un 
contrato  de  licencia. 

La  documentación  que  acompaña  al  software  resulta,  al  igual  que 
éste,  en  una  producción  del  intelecto  humano,  por  lo  cual  le  son  apli¬ 
cables  las  leyes  de  derechos  de  autor  o  de  copyright. 

Por  este  motivo,  para  poder  copiar,  modificar  o  distribuir  la  documenta¬ 
ción,  es  necesario  tener  el  permiso  del  autor  de  dicha  documentación  o 
tener  un  documento  que  le  otorga  estos  permisos.  Este  permiso  se 
corporiza  en  una  licencia  para  la  documentación. 

La  licencia  para  la  documentación  de  software  libre  generalmente  es 
la  misma  que  la  del  software  al  que  acompaña,  aunque  existen  algu¬ 
nos  documentos  publicados  bajo  licencias  específicas  para  documen¬ 
tación  como  la  free  documentaron  licence  (FDL)  de  la  Free  Software 
Foundation,  aunque  últimamente  mucha  documentación  está  siendo 
entregada  con  la  licencia  conocida  como  Creative  commons. 

En  todos  los  casos  en  los  que  vayáis  a  realizar  modificaciones  del  tra¬ 
bajo  intelectual  ajeno,  deberéis  conocer  si  tenéis  permiso  para  ha¬ 
cerlo,  si  está  especificado  en  algún  lugar  y,  en  caso  de  tener  una 
licencia,  deberéis  leerla. 


7.3.4.  Formatos  libres  v  propietarios 

Tan  importante  como  tener  las  libertades  para  la  documentación,  es 
documentar  en  formatos  libres,  de  manera  que,  una  vez  que  su  do¬ 
cumento  llegue  a  los  lectores,  pueda  ser  accedido,  modificado  y 
vuelto  a  distribuir  con  todas  las  libertades,  sin  depender  de  restriccio¬ 
nes  impuestas  al  software  de  acceso  o  modificación.  Esto  se  logra 
documentando  en  formatos  libres. 

Imaginemos  por  un  momento  que  alguien  documenta  su  software 
con  una  herramienta  que  no  se  puede  copiar  libremente,  donde 
cada  copia  requiere  de  una  licencia.  Podría  hacer  llegar  sus  docu¬ 
mentos  a  distintas  personas,  pero  éstas  estarían  obligadas  a  aceptar 
un  contrato  de  licénciamiento  para  que  puedan  leer  sus  documentos. 
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Por  otro  lado,  considerad  que  guarda  sus  documentos  en  un  formato 
(formato  binario,  formato  de  archivo  de  datos)  que  sólo  conoce  y 
maneja  una  empresa  y  que  accede  y  modifica  mediante  el  software 
de  esta  misma  empresa.  Pero  a  los  pocos  años  esa  empresa  decide 
modificar  sus  formatos  de  archivos,  o  la  empresa  cierra  el  proyecto, 
o  la  empresa  abandona  el  mercado.  Su  necesidad  de  acceder  a  la 
información  allí  guardada  seguirá  existiendo  y  tal  vez  no  pueda  ac¬ 
ceder  a  sus  propios  datos  o  textos. 

Empresarial  o  estatalmente,  manejar  archivos  de  diez  años  de  anti¬ 
güedad  (contabilidad,  declaraciones  juradas,  etc.)  es  normal  y  en 
ocasiones  obligatorio.  Posiblemente,  en  diez  años,  ni  siquiera  el  so¬ 
porte  físico  (disquetes,  CD-ROM,  DVD,  cintas)  sea  el  mismo,  mucho 
menos  el  software  para  acceder  a  los  datos,  por  lo  cual,  solamente 
si  se  han  guardado  los  datos  en  formatos  estándares  que  son  cono¬ 
cidos  por  todos  y  accesibles  para  muchos  sistemas,  podremos  visua¬ 
lizarlos. 

Los  formatos  libres  más  usados,  txt,  rtf,  html,  TeX,  XML,  etc.  están 
avalados  por  organizaciones  que  establecen  los  estándares  para 
cada  uno  de  ellos. 


7.3.5.  Herramientas  de  control  y  administración 
de  versiones 


Como  indicábamos  anteriormente,  la  documentación  debe  evolucio¬ 
nar  en  concordancia  con  el  software  que  documenta.  Es  decir,  a 
cada  nueva  versión  del  software  le  corresponderá  una  nueva  versión 
de  la  documentación.  Al  menos,  la  documentación  deberá  indicar  a 
qué  versiones  del  software  le  son  aplicables  las  distintas  opciones  do¬ 
cumentadas. 

El  software  libre  se  crea  y  desarrolla  generalmente  por  grupos  de  tra¬ 
bajo  guiados  por  un  líder  de  proyecto.  La  documentación  también  se 
realiza  mediante  un  proceso  semejante.  Para  esto,  se  utilizan  distin¬ 
tas  herramientas  que  permiten  controlar  y  versionar  la  documenta¬ 
ción  en  forma  cooperativa  y  automática,  siendo  la  más  utilizada  el 
sistema  CVS  ( concurrent  versions  system),  que  consiste  en  un  sistema 
donde  cada  autor  puede  subir  sus  textos  o  modificaciones,  y  el  siste¬ 
ma  lleva  a  cabo  un  control  automático  de  los  cambios  entre  versiones. 
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El  sistema  CVS  no  es  un  sistema  específico  para  documentación,  tam¬ 
bién  es  utilizado  para  código  fuente  o  cualquier  sistema  de  textos. 

Con  la  extensión  de  Internet,  en  los  últimos  tiempos  se  han  desarro¬ 
llado  algunos  sistemas  de  documentación  cooperativa  en  línea  que 
permiten  un  trabajo  eficaz  en  grupos  de  autores  que  trabajan  simul¬ 
táneamente.  En  particular  abordaremos  más  adelante  el  sistema 
WikiWikiWeb,  aunque  se  están  estudiando  otros  sistemas  para  este 
mismo  fin. 


7.4.  Creación  de  páginas  de  manual 


Las  aplicaciones,  utilidades  y  los  comandos  usualmente  tienen  sus  pá¬ 
ginas  de  manual  correspondientes  (llamadas  man  pages ),  que  mues¬ 
tran  las  opciones  disponibles  y  valores  de  archivos  o  ejecutables.  Las 
páginas  man  están  estructuradas  de  forma  que  los  usuarios  puedan 
buscar  fácilmente  la  información  pertinente,  lo  que  es  muy  importante 
cuando  se  está  trabajando  con  comandos  con  los  que  nunca  se  ha 
trabajado  antes. 

Se  puede  acceder  a  las  páginas  man  a  través  del  shell  escribiendo  el 
comando  man  y  el  nombre  del  ejecutable. 


7.4.1.  Secciones  de  las  páginas  de  manual 

Cada  página  de  manual  está  dividida  en  secciones  que  varían  de 
acuerdo  a  la  complejidad  del  comando  o  aplicación  que  documen¬ 
tan,  la  siguiente  es  una  lista  de  las  secciones  estándares: 

ÑAME  (nombre):  muestra  el  nombre  del  ejecutable  y  una  breve  ex¬ 
plicación  de  la  función  que  realiza. 

SYNOPSIS  (sinopsis):  muestra  el  uso  común  del  ejecutable,  tal  como 
cuáles  opciones  son  declaradas  y  qué  tipo  de  entradas  (archivos,  va¬ 
lores,  argumentos)  soporta  el  ejecutable. 

DESCRIPTION  (descripción):  muestra  las  opciones  y  valores  asocia¬ 
dos  a  un  archivo  o  ejecutable. 
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SEE  ALSO  (véase  también):  muestra  otros  términos,  archivos  o  pro¬ 
gramas  relacionados  con  el  ejecutable  de  la  página  man  consultada. 

Otras  secciones  ya  dependen  directamente  del  comando  documen¬ 
tado  en  la  página  man,  como  por  ejemplo: 

OPTIONS  (opciones):  muestra  una  descripción  de  cada  uno  de  los 
parámetros  que  puede  recibir  el  ejecutable. 

EXAMPLES  (ejemplos):  muestra  una  lista  de  invocaciones  del  ejecu¬ 
table  más  usuales. 

FILES  (ficheros):  lista  de  archivos  involucrados  para  la  debida  ejecu¬ 
ción  del  programa,  generalmente  archivos  de  configuración. 

AUTHORS  (autores):  autores  del  comando  o  programa  y  sus  direc¬ 
ciones  de  correo  electrónico. 

BUGS  (fallos):  muestra  una  lista  de  fallos  conocidos  en  el  ejecutable 
o  el  programa. 

HISTORY  (historia):  muestra  una  lista  de  las  versiones  del  documento 
man  y  de  sus  modificaciones. 

Obviamente,  el  autor  del  man  dispone  de  flexibilidad  para  agregar  las 
secciones  que  entienda  oportunas  a  los  efectos  de  tener  debidamente 
documentado  su  comando  o  programa;  de  la  misma  manera,  no  to¬ 
das  las  páginas  de  manual  poseen  todas  las  secciones  anteriores. 


7.4.2.  Camino  de  búsqueda  de  páginas  man 

Cuando  es  invocado  el  comando  man  para  mostrar  la  página  de  ma¬ 
nual  de  un  comando  determinado,  es  necesario  conocer  dónde  se  en¬ 
cuentran  disponibles  los  archivos  que  contienen  los  textos  que  hay 
que  desplegar,  esto  se  logra  mediante  la  utilización  de  MANPATH. 

MANPATH  permite  determinar  la  ruta  para  la  búsqueda  de  las  páginas 
de  manual  después  de  la  invocación  del  comando  man.  Generalmente, 
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una  distribución  de  GNU/Linux  ya  tiene  una  configuración  apropiada 
de  MANPATH  y  no  es  necesario  modificarla. 

MANPATH  tiene  dos  formas  de  ser  configurado.  Una  es  mediante  la 
configuración  de  la  variable  de  entorno  $MANPATH,  que  se  realiza 
generalmente  en  el  archivo  /etc/profile  del  sistema  con  la  línea 

MANPATH=/usr/man :  /usr/ share/man :  /usr/XHR6/man.  Y  otra 

es  mediante  el  archivo  / etc/manpath .  conf . 

La  sintaxis  para  definir  MANPATH  es  semejante  a  la  definición  del 
PATH  para  búsqueda  de  ejecutables  en  el  sistema:  la  ruta,  delimita¬ 
da  por  "dos  puntos".  MANPATH  tiene  que  contener  la  ruta  en  la  base 
de  las  jerarquías  de  capítulos  (ver  la  siguiente  sección)  de  las  páginas 
man. 

7.4.3.  Jerarquía  de  capítulos  de  las  páginas  man 

El  conjunto  de  las  páginas  man  se  clasifica  en  capítulos  que  están 
destinados  a  optimizar  las  búsquedas  y  a  permitir  que  los  sistemas 
sólo  tengan  instalados  aquellos  capítulos  que  necesitan,  dependien¬ 
do  de  su  finalidad. 

Bajo  el  directorio  definido  en  MANPATH,  se  encuentra  una  jerarquía 
de  directorios  definidos  como  manX,  donde  X  corresponde  al  capí¬ 
tulo  de  la  página  man.  Los  capítulos  son  los  siguientes: 

1)  Comandos  del  usuario 

2)  Llamadas  al  sistema  ( system  calis ) 

3)  Librerías  y  funciones  del  lenguaje  C 

4)  Dispositivos 

5)  Formatos  de  archivos 

6)  Juegos 

7)  Varios 

8)  Comandos  de  administración  del  sistema 
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7.4.4.  Generación  de  páginas  man  usando  herramientas 
estándares 


Las  páginas  de  man  son  escritas  en  un  lenguaje  de  marcas,  general¬ 
mente  conocido  como  archivo  nroff;  de  hecho,  existen  otros  pro¬ 
cesadores  para  estos  archivos  de  marcas  (como  troff  o  groff), 
pero  todos  soportan  una  sintaxis  semejante.  Nroff  es  un  lenguaje  de 
marcas  más  primitivo  que  SGML  o  HTML.  Por  otra  parte,  es  un  lengua¬ 
je  de  macros,  por  lo  que  podemos  realizar  con  él  tareas  complejas. 

Para  escribir  su  propia  página  man,  primeramente  tiene  que  tener  un 
archivo  fuente  nroff,  por  ejemplo: 


.TH  "miprograma"  1 
.SH  ÑAME 

miprograma  \-  Mi  primer  programa 
.SH  SYNOPSIS 
.B  miprograma 
miprograma  [-laFh] 

.SH  DESCRIPTION 

Mi  primer  programa  para  probar  páginas  man. 

.SH  OPTIONS 

.TP 

.B  \-l 

Parámetro  1  de  miprograma. 

.TP 

.B  \-a 

Parámetro  a  de  mi  programa. 

.TP 

.B  otros  parámetros  .  .  . 

.SH  "SEE  ALSO" 
miotroprograma ( 1 ) 

.SH  BUGS 

No  hay  errores  reportados. 


La  macro  .TH  ¡unto  al  nombre  del  programa  tiene  un  1 .  Esto  significa 
que  el  programa  que  se  está  documentando  se  archivará  en  el  capí¬ 
tulo  1  (maní)  de  las  jerarquías  de  páginas  man. 

Una  vez  que  se  dispone  del  archivo  nroff  fuente,  se  necesita  que  el 
programa  nroff  lo  interprete  para  producir  el  archivo  de  página 
man,  con  la  siguiente  línea: 


nroff  -man  miprograma . nroff  >  miprograma. 1 

El  resultado  de  la  ejecución  de  este  parámetro  es  dirigido  a  un  ar¬ 
chivo  que  se  llama  como  el  comando  y  que  tiene  la  extensión  del 
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número  del  capítulo  donde  será  archivado.  Se  puede  ver  el  resultado 
con  el  comando: 


less  miprograma.l 


Para  que  la  página  man  quede  a  disposición  para  leer  con  el  coman¬ 
do  man,  la  debe  colocar  en  el  directorio  correspondiente  del  capítulo. 


7.4.5.  Generación  de  páginas  de  manual  usando  perlpod 


Nota 


http://www.perl.org/ 

about.html 


Otra  forma  de  realizar  páginas  de  manual  es  utilizando  el  lenguaje 
de  interpretación  de  Scripts  Perl  mediante  una  utilidad  llamada 
pod2man  (además  de  pod2html,  pod2tex  y  pod2text),  que  permite 
crear  páginas  de  manual  fácilmente,  pod  quiere  decir  "Plain  Oíd 
Documentaron".  Por  ejemplo,  para  crear  la  página  de  manual  de 
un  programa  dict2docbook,  se  puede  escribir  lo  siguiente  en  un  fichero 
miprograma.pod: 


=headl  NOMBRE 

miprograma  -  Mi  primer  programa 
=headl  SYNOPSIS 
SCmiprograma  [-laFh]> 

=headl  DESCRIPCION 

Mi  primer  programa  para  probar  páginas  man. 
=headl  AUTOR 

Juan  Pueblo  E<lt>jpueblo@mail . orgE<gt> . 

=cut 


Después  se  ejecuta 


pod2man  -lax  miprograma.pod  >  miprograma.l 


para  crear  la  página  de  manual.  La  opción  lax  se  usa  para  que  se 
acepten  nombres  diferentes  a  los  habituales  para  las  secciones,  pues 
en  este  caso  están  traducidos  al  español.  La  página  creada  puede  ser 
leída  con: 


man  -1  miprograma.l 
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La  sintaxis  completa  del  pod  está  explicada  en  man  perlpod,  y  es 
bastante  simple;  también  se  debe  consultar  la  página  de  manual  de 
pod2man.  El  único  paquete  necesario  es  perl. 


Si  el  programa  que  se  quiere  documentar  está  escrito  en  perl,  el  códi¬ 
go  pod  puede  estar  dentro  del  propio  programa  y  puede  servir  tanto 
para  documentar  el  código  fuente,  como  para  crear  la  documentación 
adicional  para  man. 


|  7.5.  TeX  y  LaTeX 


TeX  es  un  programa  de  Donald  E.  Knuth,  que  está  orientado  a  la 
composición  e  impresión  de  textos  y  fórmulas  matemáticas. 

LaTeX  es  un  paquete  de  macros  que  permite  al  autor  de  un  texto 
componer  e  imprimir  un  documento  con  calidad,  empleando  patro¬ 
nes  definidos.  Originalmente,  LaTeX  fue  escrito  por  Leslie  Lamport  y 
utiliza  TeX  como  su  elemento  de  composición.  LaTeX  es  una  potente 
herramienta  de  procesamiento  de  textos  científicos  que  aún  no  ha 
sido  sustituida  por  los  modernos  editores  de  texto  en  el  mundo  de  las 
editoriales  científicas  y  académicas.  Hay  quienes  afirman  que  LaTeX 
es,  probablemente,  el  mejor  procesador  de  textos  del  mundo,  pero 
tiene  el  inconveniente  de  que  no  se  trabaja  de  forma  WYSIWYG 
(What  you  see  is  what  you  get)  lo  que  dificulta  en  gran  medida  su  uso 
por  parte  de  personas  acostumbradas  a  editores  de  texto. 

La  gran  problemática  que  presentan  los  editores  de  textos  WYSIWYG 
es  que  el  autor  (usuario)  debe  estar  continuamente  observando  el  for¬ 
mato  de  los  textos  (el  título  va  centrado,  la  numeración  de  las  viñetas, 
el  formato  de  los  párrafos,  etc.),  mientras  que  con  LaTeX  el  autor  pue¬ 
de  dedicarse  exclusivamente  al  texto  (contenido)  sin  necesidad  de  dis¬ 
traer  la  atención  en  la  presentación.  Esta  separación  entre  contenido  y 
presentación,  en  ambientes  de  producción  (como  un  periódico)  es  na¬ 
tural  y  existen  roles  diferentes  para  cada  una:  el  autor  y  el  diseñador. 
Los  editores  de  texto  modernos  obligan  al  autor  a  ocuparse  de  las 
tareas  del  diseñador. 

Con  LaTeX  el  autor  solamente  deberá  ocuparse  del  texto,  del  conte¬ 
nido;  dejará  que  el  programa  se  encargue  de  la  presentación.  Así, 
un  mismo  texto  será  presentado  de  diferente  modo  si  es  para  impri¬ 
mir  en  formato  A4  o  carta,  si  su  destino  es  un  pdf  o  una  página  web. 
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LaTeX  no  sólo  se  ocupa  de  las  tareas  de  presentación  final,  también 
de  la  numeración  de  los  capítulos,  los  índices  temáticos,  los  enlaces 
cruzados,  la  organización  de  la  bibliografía  citada,  los  enlaces  web, 
la  inclusión  de  otros  archivos,  la  numeración  de  páginas,  las  notas 
al  pie,  etc. 

LaTeX  nació  en  UNIX,  con  lo  que  está  disponible  en  plataformas 
con  este  sistema  operativo,  incluyendo  ordenadores  personales  con 
GNU/Linux.  Como  ocurre  con  muchos  programas  de  libre  distribución, 
ha  sido  importado  con  éxito  a  otras  muchas  plataformas,  incluyendo 
DOS/Windows.  Este  es  otro  punto  a  favor  de  LaTeX:  la  posibilidad  de 
trabajar  con  él  virtualmente  en  todas  las  plataformas  hardware  y 
software  existentes. 


7.5.1.  Instalación 

Sobre  la  instalación  de  LaTeX  no  vamos  a  detallar  demasiado,  ya 
que  afortunadamente  forma  parte  de  los  paquetes  de  las  distribucio¬ 
nes  de  GNU/Linux  más  usadas  actualmente,  por  lo  que  la  instalación 
es  completamente  automática.  Destacamos,  sin  embargo,  que  hay 
que  tratar  de  instalarse  todos  los  paquetes  de  LaTeX  (excepto  algunos 
evidentes,  como  los  soportes  de  idiomas  orientales  y  otras  rarezas), 
haciendo  énfasis  en  las  herramientas  de  visualización  y  conversión 
de  ficheros  procesados  .DVI  (dvips,  xdvi...),  lo  que  nos  permitirá  im¬ 
primir  o  ver  el  resultado  por  pantalla. 


7.5.2.  Utilización 

El  uso  de  LaTeX  es  parecido  al  de  un  compilador,  por  eso  es  deno¬ 
minado  "procesador  de  textos"  (a  diferencia  de  los  "editores  de  tex¬ 
to").  Los  pasos  que  hay  que  seguir  en  un  documento  son  los 
siguientes: 

1 )  Escribir  el  texto  código  fuente  con  la  sintaxis  (o  marcas)  de  LaTeX  con 
cualquier  editor  de  textos  ASCII  (se  recomienda  alguno  que  destaque  las 
marcas  con  colores). 
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2)  Se  compila  el  fichero  escrito,  escribiendo  el  comando  látex 
fichero . tex . 


3)  Se  visualiza  el  resultado  en  formato  gráfico  con  el  visor  de  dvi  con  el 
comando xdvi  fichero. dvi. 

4)  Se  reedita  el  fichero  para  corregir  o  continuar  el  trabajo,  y  finalmente 
se  imprime  con  el  comando  dvips  fichero. dvi.  o  se  transforma  a  forma¬ 
tos  pdf,  html  o  rtf. 


7.5.3.  Fichero  fuente  LaTeX 

El  siguiente  es  un  ejemplo  de  un  documento  básico  en  látex: 


\documentclass [a4paper, llpt] {article} 
\userpackage [activeacute, spanish] {babel } 
\author{Juan  Pueblo} 

\title{Mi  primer  documento  LaTeX} 

\begin { document } 

\maketitle 
\tableofcontents 
\section{ Introducción} 

La  primer  parte  del  documento  y  un  párrafo. 


Otro  párrafo  de  la  introducción: 


\section {Ultima  parte} 


La  última  parte  y  aquí  se  acaba: 


\end{ document} 


7.5.4.  Clases  de  documentos 

La  instalación  estándar  de  Látex  ya  trae  un  grupo  importante  de  do¬ 
cumentos  que  pueden  ser  utilizados  para  lograr  distintos  resultados: 

•  article  para  artículos  de  revistas  especializadas,  ponencias,  traba¬ 
jos  de  prácticas  de  formación,  trabajos  de  seminarios,  informes 
pequeños,  solicitudes,  dictámenes,  descripciones  de  programas, 
invitaciones  y  muchos  otros. 

•  report  para  informes  mayores  que  constan  de  más  de  un  capítu¬ 
lo,  proyectos  de  fin  de  carrera,  tesis  doctorales,  libros  pequeños, 
disertaciones,  guiones  o  similares. 


book  para  libros. 


•  slide  para  transparencias.  Esta  clase  de  documentos  producirá 
páginas  con  tipos  grandes  de  caracteres. 


7.5.5.  Extensiones  o  paquetes 

Una  de  las  ventajas  de  LaTeX  es  que  puede  ser  extendido  para  abar¬ 
car  situaciones  donde  el  sistema  básico  no  soluciona  el  problema, 
como  son  inclusión  de  gráficos,  textos  a  colores,  códigos  fuente  a 
partir  de  ficheros,  etc.  Para  esto  se  utilizan  los  paquetes  mediante  la 
orden: 

\usepackage [opciones] {paquete} 

En  el  ejemplo  básico  previo  se  incluye  el  paquete  babel,  que  permite 
la  expansión  de  los  caracteres  para  incluir  los  del  idioma  español. 


7.5.6.  Edición  WYSWYG  con  LaTeX 


Nota 


http://www.lyx.org 


Si  bién  LaTeX  está  orientado  a  trabajar  como  se  indica  anteriormen¬ 
te,  existe  un  editor  WYSWYG  llamado  Lyxque  hace  un  procesamien¬ 
to  en  tiempo  de  escritura  del  documento  LaTeX.  No  obstante,  debido 
a  que  el  resultado  de  un  texto  procesado  con  LaTeX  es  fijo,  de  acuer¬ 
do  a  la  clase  del  documento,  el  lyx  no  puede  ser  usado  en  la  misma 
forma  de  flexibilidad  que  un  editor  WYSWYG;  aunque  es  muy  fácil 
acostumbrarse  a  escribir  con  LYX.  Lyx  también  está  portado  para  co¬ 
rrer  en  múltiples  sistemas  operativos. 


Algunos  editores  WYSWYG  poseen  la  capacidad  de  guardar  los  do¬ 
cumentos  en  formato  de  fuente  LaTeX;  también  hay  herramientas 
que  convierten  documentos  de  otros  formatos  a  .tex.  No  obstante, 
para  el  usuario  medianamente  entrenado  en  LaTeX,  siempre  va  a  ser 
más  fácil  editar  con  cualquier  editor  y  procesar  con  látex  sus  textos. 


p.6.  SGML 


SGML  son  las  siglas  de  standard  generallzed  markup  language  y  es 
un  sistema  para  organizar  y  etiquetar  elementos  en  un  documento. 

262 


SGML  fue  desarrollado  como  un  estándar  internacional  por  la  Inter¬ 
national  Organization  for  Standards  (ISO)  in  1  986.  SGML  por  sí  mis¬ 
mo  no  especifica  ningún  formato  en  particular,  pues  es  la  norma  que 
determina  las  reglas  para  incluir  etiquetas  de  marcado  en  los  docu¬ 
mentos.  Y  estas  etiquetas  pueden  ser  interpretadas  por  elementos  de 
lectura,  presentación,  recuperación  de  información,  etc.,  de  diferen¬ 
tes  maneras. 

SGML  es  utilizado  en  grandes  documentos  que  son  objeto  de  fre¬ 
cuentes  revisiones  y  requieren  ser  impresos  en  diferentes  formatos. 
Como  SGML  es  un  sistema  complejo  y  amplio,  no  es  utilizado  en  for¬ 
ma  masiva.  No  obstante,  el  estándar  HTML  para  el  World  Wide  Web 
es  una  implementación  de  SGML;  es  decir,  el  HTML  es  un  conjunto 
de  etiquetas  que  siguen  el  estándar  SGML  al  ser  incluidas  en  un  do¬ 
cumento. 


7.6.1.  Documentación  en  formato  html 

Son  muchos  los  editores  que  permiten  guardar  documentos  en  for¬ 
mato  HTML,  dejándolos  listos  para  ser  publicados  en  un  servidor 
web.  No  obstante,  cuando  hablamos  de  documentación  de  software 
libre,  tenemos  que  pensar  en  documentos  que  deben  ser  modifica¬ 
dos  por  distintas  personas  y  frecuentemente,  por  lo  que  se  requieren 
herramientas  más  complejas  que  un  editor  de  textos. 


Herramienta  web  de  documentación  cooperativa: 
el  WikiWikiWeb 

Frente  a  la  problemática  de  editar  documentación  por  diferentes  au¬ 
tores,  que  se  mantengan  versiones  de  cada  documento  y  que  esos 
documentos  estén  en  línea  inmediatamente,  se  creó  una  herramienta 
llamada  wikiwikiweb. 

El  término  de  WikiWiki  (wiki  wiki  significa  rápido  en  la  lengua  hawaia- 
na)  se  utiliza  en  muchos  sitios  web  Internet  para  nombrar  una  colec¬ 
ción  de  páginas  web  de  hipertexto,  cada  una  de  las  cuales  puede  ser 
visitada  y  editada  por  cualquier  persona.  Una  versión  web  de  un  wiki 
también  se  llama  WikiWikiWeb.  Se  trata  de  un  simple  juego  de  pala¬ 
bras,  ya  que  las  iniciales  son  WWW  como  en  la  World  Wide  Web. 
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Nota 


http://www.c2.com/cgi/ 
wiki?  WelcomeVisitors 


Nota 


http://es.wikipedia.org 


La  forma  abreviada  wiki  denomina  a  la  aplicación  de  informática  co- 
laborativa  que  permite  crear  colectivamente  documentos  web  usan¬ 
do  un  simple  esquema  de  etiquetas  y  marcas,  sin  que  la  revisión  del 
contenido  sea  necesaria  antes  de  su  aceptación  para  ser  publicado 
en  el  sitio  web  en  Internet. 

Dada  la  gran  rapidez  con  la  que  se  actualizan  los  contenidos,  la 
palabra  wiki  adopta  todo  su  sentido.  El  documento  de  hipertexto  re¬ 
sultante,  denominado  también  wiki  o  WikiWikiWeb,  lo  produce  típi¬ 
camente  una  comunidad  de  usuarios.  Muchos  de  estos  lugares  son 
inmediatamente  identificadles  por  su  particular  uso  de  palabras  en 
mayúsculas,  o  texto  capitalizado;  uso  que  consiste  en  poner  en  ma¬ 
yúsculas  las  iniciales  de  las  palabras  de  una  frase  y  eliminar  los  espa¬ 
cios  entre  ellas,  como  por  ejemplo  en  EsteEslInEjemplo.  Esto  convierte 
automáticamente  a  la  frase  en  un  enlace.  Este  wiki,  en  sus  orígenes,  se 
comportaba  de  esa  manera,  pero  actualmente  se  respetan  los  espa¬ 
cios  y  sólo  hace  falta  encerrar  el  título  del  enlace  entre  dos  corchetes. 

El  objetivo  de  un  wiki  es  democratizar  la  creación  y  el  mantenimiento 
de  las  páginas,  al  eliminar  el  síndrome  de  un  único  webmaster  o  ad¬ 
ministrador. 

El  gran  potencial  del  wiki  radica  en  que  no  es  necesario  aprender  a 
utilizar  complicadas  etiquetas  HTML  para  escribir  de  forma  sencilla 
documentos  y  establecer  enlaces  desde  el  sitio  web. 

El  primer  WikiWikiWeb  fue  creado  por  Ward  Cunningham,  quien  in¬ 
ventó  y  dio  nombre  al  concepto  wiki,  y  produjo  la  primera  implemen- 
tación  de  un  servidor  WikiWiki.  En  palabras  del  propio  Ward,  un  wiki 
es  "la  base  de  datos  en  línea  más  simple  que  posiblemente  pudiera 
funcionar"  ( the  simplest  online  database  that  could  possibly  work). 

En  principio,  un  wiki  se  usa  para  cualquier  cosa  que  sus  usuarios  de¬ 
seen  y  está  siendo  adoptado  para  documentar  mucho  software  libre 
en  forma  cooperativa.  El  formato  se  presta  a  la  colaboración,  cola¬ 
boración  que  involucra  a  cualquier  persona. 

Un  ejemplo  es  Wikipedia;  un  wiki  que  tiene  como  misión  específica 
ser  una  enciclopedia  libre  y  actualizada  por  todo  aquel  que  lo  desee. 
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7.6.2.  Documentación  en  formato  Docbook 


DocBook  es  un  dialecto  de  SGML  (como  lo  es  HTML)  especialmente 
orientado  a  la  escritura  de  documentación  técnica.  En  particular  es 
una  aplicación  del  estándar  SGML/XML,  que  incluye  una  DTD  propia 
y  que  se  utiliza  de  manera  más  destacada  en  el  área  de  la  documen¬ 
tación  técnica,  especialmente  para  documentar  todo  tipo  de  material 
y  programas  informáticos.  Existe  un  Comité  Técnico  de  DocBook  en 
OASIS  (originalmente  SGML  Open)  que  mantiene  y  actualiza  este  es¬ 
tándar.  DocBook  inicialmente  comenzó  como  una  DTD  de  SGML, 
pero  a  partir  de  la  versión  4  existe  un  equivalente  para  XML. 

DocBook  es  muy  utilizado  en  algunos  contextos,  entre  los  que  desta¬ 
can  Linux  Documentation  Project  (Proyecto  de  documentación  Linux), 
las  referencias  de  las  API  de  GNOME  y  GTK+,  así  como  la  docu¬ 
mentación  del  núcleo  Linux.  Las  páginas  man  del  entorno  operativo 
Solaris  se  generan  también  a  partir  de  documentos  que  utilizan  las 
DTD  de  DocBook. 

Norman  Walsh  y  el  equipo  de  desarrollo  del  DocBook  Open  Reposi- 
tory  mantienen  un  conjunto  de  hojas  de  estilo  DSSSL  y  XSL  para  ge¬ 
nerar  versiones  PDF  y  HTML  de  documentos  DocBook  (así  como  para 
desarrollar  otros  formatos,  incluyendo  páginas  de  referencia  man  y 
de  ayuda  en  HTML).  Walsh  es  también  el  principal  autor  del  libro 
DocBook:  The  Deflnltive  Guide,  la  documentación  oficial  de  DocBook. 
Este  libro  se  puede  obtener  bajo  licencia  GFDL  o  en  su  versión  impre¬ 
sa  está  editada  por  O'Reilly  &  Associates." 


Instalación  y  consideraciones  preliminares 

Para  poder  utilizar  DocBook  y  poder  sacar  un  mejor  provecho  de  la 
escritura,  se  recomienda  tener  instalados  las  siguientes  utilidades: 

DocBook  y  utilidades:  estos  paquetes  son  requeridos  para  que  todo 
funcione  debidamente;  generalmente  las  distribuciones  de  GNU/Linux 
ya  traen  paquetes  prontos  para  instalar. 

emacs:  si  bien  los  documentos  pueden  ser  editados  con  cualquier 
editor  de  textos,  Emacs  es  el  único  editor  orientado  al  contexto  (fun¬ 
cionalidad  muy  útil  a  la  hora  de  editar  DocBook). 
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Nota 


http://www.oasis-open.org/ 


Modo  PSGML  de  emacs:  soporte  para  trabajar  con  la  DTD  de 
DocBook  en  el  momento  de  edición  en  Emacs. 


Fichero  fuente  DocBook 

El  siguiente  es  un  ejemplo  de  un  documento  básico  DocBook: 


< ! doctype  book  PUBLIC  "-//OASIS/ /DTD  DocBook  V4.1//EN"> 

<book  lang=es> 

<bookinf o> 

<title>Mi  primer  documento  DocBook</title> 

<subtitle>Un  subtitulo</subtitle> 

</bookinfo> 

<tocx/toc> 

<!--  Puede  poner  un  comentario  o  directamente  comenzar  a  escri¬ 
bir  el  documento  --> 

<chapter> 

<title>Introducción</title> 

<para>La  primera  parte  del  documento  y  un  párrafo. </para> 

<para>Otro  párrafo  de  la  introducción</para> 

</chapter> 

<chapter> 

<title>Última  parte</title> 

<para>La  última  parte  y  aquí  se  acaba. </para> 

</chapter> 

</book> 

La  utilización  para  editar  este  documento  de  una  herramienta  orien¬ 
tada  al  contexto  (emacs+psgml)  le  permitirán  tener  una  sintaxis  con¬ 
trolada,  es  decir,  no  le  dejarán  escribir  <title>  si  aún  no  ha  abierto 
un  <chapter>,  ya  que  el  editor  sabe  qué  etiquetas  tiene  disponibles 
dentro  del  contexto  en  el  que  se  encuentra  escribiendo. 


Utilización 

Una  vez  que  tenga  su  documento  escrito  en  DocBook,  debería  revisarlo 
para  conocer  si  no  ha  cometido  ningún  error  de  sintaxis  (cerrar  una  eti¬ 
queta;  texto  en  una  etiqueta,  etc.),  para  esto  existe  el  siguiente  comando: 


nsgmls  -s  midocumento . sgml 


Ahora  deberá  decidir  qué  salida  desea  para  su  documento  y  lo  pue¬ 
de  hacer  utilizando  los  procesadores  de  textos  db2html,  db2ps, 
db2pdf,  db2rtf,  de  la  siguiente  forma: 


db2pdf  midocumento. sgml 
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7.7.  Doxygen.  Documentación  de  código  fuente 

Doxygen  es  un  sistema  de  documentación  para  códigos  fuente  de  pro¬ 
gramas  escritos  en  una  variedad  importante  de  lenguajes,  entre  los  que 
se  encuentra:  C  +  +  ,  C,  Java,  Objective-C,  IDL  (Corba),  PHP,  C#  y  D. 

Doxygen  puede  generar  documentación  para  ser  publicada  en  Inter¬ 
net  o  para  ser  procesada  con  LaTeX.  También  puede  generar  salidas 
en  formatos  rtf,  postscript,  pdf  y  páginas  de  manual  de  UNIX. 

La  idea  detrás  de  Doxygen  es  documentar  en  el  propio  código  fuen¬ 
te,  a  medida  que  éste  se  escribe,  de  forma  tal  que  Doxygen  extrae  la 
documentación  del  propio  código  fuente. 

Doxygen  fue  creado  bajo  GNU/Linux  y  Mac  OS  X,  pero  ha  sido  por¬ 
tado  para  la  mayoría  de  los  sistemas  UNIX  y  también  para  Windows. 

7.7.1.  Utilización 

Doxygen  utiliza  un  archivo  de  configuración  para  determinar  cómo 
debe  procesar  la  documentación.  Cada  proyecto  deberá  tener  su 
propio  archivo  de  configuración  que  entre  otras  cosas  incluirá  qué 
código  fuente  debe  ser  analizado,  qué  directorios,  etc. 

Existe  una  forma  simple  de  crear  una  plantilla  del  archivo  de  confi¬ 
guración  con  el  comando: 

doxygen  -g  archivo-config 

Las  más  nuevas  versiones  de  doxygen  traen  una  utilidad  llamado 
doxywizard,  que  permite  editar  el  archivo  de  configuración  de  una 
forma  gráfica  mediante  diálogos. 

Para  un  proyecto  pequeño  constituido  por  una  fuente  en  C  o  C  +  +  , 
no  es  necesario  hacer  modificaciones,  ya  que  doxygen  buscará  los 
archivos  de  fuentes  en  el  directorio  actual. 

Para  generar  la  documentación  basta  con  ejecutar  el  comando: 


doxygen  archivo-config 
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7.7.2.  Documentando  en  los  códigos  fuente 


La  documentación  dentro  de  los  códigos  fuente  debe  ser  realizada 
dentro  de  bloques  especiales  de  texto  que  puedan  ser  reconocidos 
por  doxygen  y  a  su  vez  no  interfieran  con  el  compilador  del  lenguaje. 

Dentro  de  cada  bloque  de  documentación  existen  dos  tipos  de  des¬ 
cripciones,  que  ¡untándolas  se  crea  la  documentación: 

•  descripción  abreviada 

•  descripción  detallada 

Para  marcar  un  bloque  como  una  descripción  detallada,  como  por 
ejemplo,  utilizando  el  estilo  JavaDoc,  que  es  un  formato  de  bloque 
de  comentario  tipo  C,  iniciando  con  un  asterisco,  como  este  ejemplo: 


/  *  * 

*  ...  texto  . . . 
*/ 


También  es  posible  utilizar  un  formato  de  comentario  tipo  Qt,  que  es 
un  formato  de  bloque  de  comentario  tipo  C,  iniciado  con  un  símbolo 
de  exclamación,  como  por  ejemplo: 


/*  ! 

*  ...  texto  . . . 
*/ 


En  ambos  casos,  el  asterisco  intermedio  es  opcional,  o  sea,  que  se 
puede  aceptar: 


/*  ! 

. . .  texto  . . . 
*/ 


Una  tercera  forma  de  marcar  un  bloque  es  con  la  notación  de  co¬ 
mentario  de  C  +  + ,  que  se  individualiza  con  una  barra  adicional: 
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/// 

///  ...  texto  . . . 
/// 


o  también 


//! 

// !  ...  texto  . . . 
//! 


Para  individualizar  la  descripción  abreviada,  también  existen  varias 
posibilidades  de  marcado. 


Una  forma  es  iniciar  la  línea  con  el  comando 


\brief 


en  alguno  de  los  formatos  de  bloques  detallados  anteriormente,  se¬ 
guidos  de  una  línea  en  blanco: 


/*!  \brief  Descripción  abreviada. 

*  Continuación  de  la  descripción  abreviada. 

•k 

*  ...  texto  . . . 

*/ 


Si  el  archivo  de  configuración  se  configura  con  la  opción 
JAVADOC_AUTOBRIEF  en  YES,  es  posible  utilizar  el  estilo  de  bloques 
de  JavaDoc  que  automáticamente  inicia  la  descripción  abreviada 
hasta  el  próximo  punto  seguido  de  un  espacio  o  una  nueva  línea; 
como  en  este  ejemplo: 


/**  Descripción  abreviada  que  termina  en  un  punto.  Descripción 
*  detallada  que  comienza  después. 

*/ 


Un  tercer  método  para  diferenciar  los  tipos  de  descripciones  es  utili¬ 
zar  un  comentario  en  formato  C  +  +  en  una  sola  línea. 


///  Descripción  abreviada. 
/**  Descripción  detallada  */ 


o  también  dejando  una  línea  en  blanco  entre  una  y  otra  descripción: 

//!  Descripción  abreviada. 


//!  Descripción  detallada 
//!  en  más  de  un  renglón 
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En  este  último  caso  tendrá  que  tener  explícitamente  indicado 
JAVADOC_AUTOBRIEF  en  NO  para  que  sean  propiamente  detecta¬ 
das  las  descripciones. 

Esto  muestra  como  doxygen  es  flexible  para  adaptarse  a  los  formatos 
de  comentarios  de  cada  uno  de  los  desarrolladores  de  software. 


7.8.  Conclusiones 

La  documentación  en  software  libre  adquiere  una  relevancia  mucho 
mayor  que  en  sistemas  de  licénciamiento  privativos,  ya  que  en  soft¬ 
ware  libre  se  busca  la  cooperación  en  el  desarrollo;  por  ello,  tener 
una  buena  documentación  ayudará  a  los  desarrolladores  y  usuarios 
a  conocer  mejor  y  más  rápidamente  la  herramienta  de  software, 
quedando  habilitados  a  cooperar  con  el  proyecto,  ya  sea  informan¬ 
do  de  errores,  proponiendo  mejoras,  aportando  código  o  contestan¬ 
do  preguntas  a  otros  usuarios  y  desarrolladores. 

Los  sistemas  de  documentación  aquí  presentados  permiten  tener  una 
idea  de  las  características  generales  de  cada  uno  de  ellos  y  son  una 
breve  guía  para  poder  construir  un  documento  básico  utilizando  las 
herramientas  descritas;  dependerá  ahora  del  alumno  profundizar  en 
el  o  los  sistemas  que  considere  más  apropiados  para  obtener  un  co¬ 
nocimiento  completo  de  ellos. 


7.9.  Otras  fuentes  de  referencia  e  información 

Referencias  de  Tex  y  Látex 

Michael  Doob.  A  Genf/e  Introducción  to  TeX. 

George  Gratzer.  First  Steps  ¡n  LaTeX. 

SGML 

SGML  for  Dummies  (SGML  para  principiantes) 

Developing  SGML  DTDs:  From  text  to  Model  to  Markup 

DocBook 

DocBook:  the  definitive  guide 

Doxygen 

http://www.stack.nl/~dimitri/doxygen/manual.html 
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8.  Comunidades  virtuales  y  recursos  existentes 


8.1 .  Introducción 

Desde  sus  comienzos,  el  desarrollo  del  software  libre  ha  estado  muy 
relacionado  con  el  desarrollo  de  Internet. 

En  un  principio  los  desarrolladores  se  comunicaban  mediante  listas 
de  correo  en  las  redes  precursoras  de  Internet  y  en  la  medida  en  que 
se  desarrollaba  éstas,  también  lo  hacia  su  manera  de  comunicarse. 

Con  el  actual  crecimiento  de  la  red  y  los  nuevos  lenguajes  de  desa¬ 
rrollo  web,  hemos  llegado  a  un  punto  en  el  que  la  cantidad  de  ser¬ 
vicios  ofrecidos  en  portales  para  los  desarrolladores  e  ingenieros  de 
software  es  enorme,  y  no  sólo  abarca  herramientas  que  ayudan  a  és¬ 
tos  en  su  desarrollo  diario,  sino  que  ponen  en  contacto  a  patrocina¬ 
dores  de  proyectos  con  desarrolladores,  de  modo  que  el  software 
libre  pueda  crecer  y  expandirse. 

Por  otra  parte,  los  desarrolladores  encuentran  lugares  en  los  que 
pueden  publicitarse  ellos  mismos,  consiguiendo  así  una  notoriedad 
muy  valiosa  para  su  desarrollo  personal  y  laboral. 


8.2.  Objetivos 

Tras  concluir  el  capítulo,  el  lector  será  capaz  de  lo  siguiente: 

•  Valorar  las  opciones  en  las  que  publicitar  sus  proyectos  de  software 
o  los  que  son  gestionados  para  terceros. 

•  Conocer  el  funcionamiento  de  los  portales  más  comunes  como 
Freashmeat  y  Sourceforge,  aprendiendo  el  sistema  de  creación  de 
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una  cuenta  personal,  una  de  proyecto  y  la  gestión  de  ésta,  no  sólo 
del  proyecto  sino  de  sus  subscriptores. 


8.3.  Recursos  documentales  para  el  ingeniero 
en  software  libre 


En  este  punto  tratamos  de  mostrar  los  recursos  documentales  más 
conocidos  a  través  de  los  que  el  ingeniero  de  software  libre  dispon¬ 
drá  no  sólo  de  manuales,  sino  de  cursos,  guías,  normativa,  tipos  de 
licencia  e  incluso  en  algunos  casos  proyectos  completos  de  los  que 
tomar  ejemplo  para  elaborar  el  nuestro. 


8.3.1.  http://www.tldp.ora 

Las  siglas  tldp  significan  The  Linux  Documentation  Proyect.  Esta  pá¬ 
gina  tiene  versión  en  distintos  idiomas: 


Figura  1 


Archivo  Editar  Y*r  y  (jare  ador*»  M«rt  amienta*  Verana  Ayuda 


i 

Recargar 


4  http:0Www.tRJp.org/ 


•ftlnéclo  (Marcador*»  ^Mandrake»ort  ¿Mandrafcettor*  ¿Mandrakeclub  ¿Mandrake*xp»rt  ^Manorakeonitn*  ¿Thawte  ¿LPI 


¿TLDP-ES:  P agina  Principal 


f  The  Unux  Oocum«ntatton  Pro|*ct 


The  ^ 

Linux 

Documentation 
P  roject 


Vs 


Author  /  Contribute 


HOWTOa:  sutoject-speofic  hdp 

lai»»t  ucdui  I  mainind*»  |  brew 

Quides:  longer.  in-dcpth  books 
late»!  nodal*»  man  inri*» 

FAQ»  Frequentty  Asked  Questions 


man  paqea:  help  on  individual  corrunands 
Unux  Gaxettc  Online  maga/ me 
UnuxFocus.  muittngual  onime  maga/ me 


Esparto] 

Frsncal» 


K  orean 

poHufluAs  do  Brasil 


Nfl  J  recur»os_programj  _J  Sin  nombrel  Oper|3  pue 


¡  ¡S  The  Linux  Oocurrver  ama  &  ./  10:49  í$  Qj 


Desde  éste  podemos  acceder  a  mucha  documentación  libre: 
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1)  Guías 

2)  Cornos 

3)  Faqs 


4)  Páginas  de  manual  Linux 

5)  Manuales 

6)  Cursos 

Además,  tendremos  acceso  a  varios  servicios  como  el  de  publicacio¬ 
nes,  de  desarrollo  de  proyectos,  enlaces  con  otros  proyectos  y  pági¬ 
nas  en  general 

8.3.2.  http://www.freestandards.org 

Esta  organización  (Free  Standards  Group)  independiente  tiene  como 
intención  acelerar  el  uso  del  software  libre  y  de  código  abierto  me¬ 
diante  el  desarrollo  y  la  promoción  de  estándares  o  reglas. 

Para  ello,  crea  herramientas  de  ayuda  para  desarrolladores  de  software 
libre.  Además,  se  encarga  de  testear  y  certificar  mediante  programas 
que  el  software  desarrollado  sigue  los  estándares  existentes. 

Otra  función  de  este  grupo  es  ayudar  a  migrar  al  sistema  operativo  Linux 
para  aquellos  que  estén  acostumbrados  a  manejar  otros  entornos. 


Figura  2 


3»  2  ¿«a  manual. floc  -  (|^J  ftcufsos_proqt|  3  put _ |  JTLDP  ES:  Luo{0  Standard*  iMIPiPI  tt n  »  «  g| 


En  la  página  tendremos  información  mediante  noticias  y  prensa 
acerca  de  todo  el  desarrollo  de  software  libre,  acerca  de  empresas 
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relacionadas  con  el  campo  y  sus  nuevos  proyectos  dentro  del  área 
de  Linux. 


Nota 


http://www.linuxbase.org 


Se  dan  certificaciones  a  vendedores  de  software  a  través  de  LSB  (Linux 
Standard  Base).  Desde  la  página  hay  un  enlace  a  LSB  a  través  del  cual 
se  pueden  recibir  las  certificaciones  antes  descritas.  LSB  es  un  grupo  de 
trabajo  de  freestandards,  pero  no  el  único. 


Además,  están  los  siguientes: 

•  Openil8n.  http://www.openil8n.org/ 

•  LANANA.  http://www.lanana.org/ 

•  Openprinting.  http://www.openprinting.org/ 

•  Accesibility.  http://accessibility.freestandards.org 

•  DWARF.  http://dwarf.freestandards.org/ 

•  Open  Cluster.  http://www.opencf.org/home.html 


Cada  uno  de  los  grupos  de  trabajo  se  encarga  de  un  área  distinta 
dentro  del  entorno  del  software  libre  y  por  tanto  de  Linux. 


8.3.3.  http://www.unix.org 

Este  producto,  así  como  la  página,  pertenecen  a  una  empresa  deno¬ 
minada  Open  Group,  que  está  especializada  en  el  desarrollo  de  es¬ 
tándares  globales  e  integración  de  información  para  una  interacción 
global.  La  tecnología  que  vende  pretende  ser  neutral  y,  por  tanto,  si¬ 
gue  los  paradigmas  que  se  persiguen  dentro  del  software  libre  y  en 
consecuencia  del  sistema  operativo  Linux. 


UNIX  es  el  sistema  operativo  predecesor  de  Linux.  Muchas  de  las 
características  de  Linux  se  heredan  de  UNIX  (sistema  robusto,  esta¬ 
ble,  multiusuario,  multitarea,  multiplataforma,  etc.).  Por  ello  esta 
página  proporciona  información  de  gran  interés  dentro  del  entorno 
del  software  libre.  Desde  estándar,  certificaciones  hasta  consultas 
y  noticias  relacionadas  con  el  sistema  operativo.  Además  posee 
foros  con  un  objetivo  claro  de  reunir  a  profesionales  para  poner 
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en  común  conocimientos  relacionados  con  el  sistema  y  el  software 
que  se  ejecuta  en  él. 


Figura  3 
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8.3.4.  http://www.opensource.org 

Es  una  organización  sin  ánimo  de  lucro  cuyo  objetivo  es  gestionar  y 
promocionar  la  definición  de  "código  abierto"  para  el  bien  de  la  co¬ 
munidad. 


La  licencia  "código  abierto"  implica  una  serie  de  características  con¬ 
cretas: 


1)  Libre  redistribución. 

2)  Acceso  al  código  fuente. 

3)  Permiso  de  realizar  trabajos  derivados. 

4)  Garantía  de  la  integridad  del  código  fuente  del  autor. 

5)  No  discriminación  a  personas  o  grupos. 

6)  No  discriminación  a  ningún  posible  campo  de  la  aplicación. 

7)  Libertad  para  la  distribución  de  la  licencia. 

8)  La  licencia  no  debe  ser  específica  de  un  producto. 

9)  La  licencia  no  debe  poner  restricciones  de  uso  sobre  otro  software. 
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La  página  ofrece  los  parámetros,  marca  las  pautas  de  la  definición  y 
define  estándares  del  término  "Open  Source"  y  lo  que  conlleva. 


8.3.5.  http://standards.ieee.org/readinq/ieee/ 
std  public/description/posix/ 

Esta  página  se  dedica  por  completo  a  la  definición  de  estándares  bajo 
la  normativa  IEEE  (Institute  of  Electrical  and  Electronic  Engineering). 
Concretamente  de  estándar  POSIX. 


POSIX  son  las  iniciales  de  portable  operating  system  interface.  Es  un 
estándar  que  pretende  conseguir  la  portabilidad  del  software  al  nivel 
del  código  fuente.  En  otras  palabras:  un  programa  escrito  para  un 
SO  que  sea  compatible  con  POSIX  ha  de  poderse  compilar  y  ejecutar 
sobre  cualquier  otro  "POSIX",  aunque  sea  de  otro  fabricante  distinto. 
El  estándar  POSIX  define  la  interfaz  que  el  SO  debe  ofrecer  a  las  apli¬ 
caciones:  el  juego  de  llamadas  al  sistema.  POSIX  está  siendo  desa¬ 
rrollado  por  IEEE  y  estandarizado  por  ANSI  (American  National 
Standards  Institute)  e  ISO  (International  Standards  Organization). 
Evidentemente,  POSIX  está  basado  en  UNIX. 
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8.3.6.  http://www.faas.org 


FAQS  (frequently  asked  questions  -  preguntas  frecuentes)  pretende 
responder  a  todas  aquellas  preguntas  relacionadas  con  el  mundo  de 
la  informática,  el  software,  los  sistemas  operativos,  así  como  otros 
campos  no  directamente  relacionados  con  la  tecnología. 


Se  puede  acceder  a  ellos  por  categorías,  por  autor,  por  número  de 
referencia,  etc. 


En  cada  FAQ  tendremos  LOS  RFC  ( request  for  comments)  correspon¬ 
dientes,  es  decir,  respuestas  a  las  preguntas  frecuentes.  La  base  de 
datos  es  muy  extensa,  por  lo  que  muchas  veces  es  necesario  hacer 
búsquedas  por  alguno  de  los  campos  que  definen  las  preguntas  y  las 
respuestas. 
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Figura  6 
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8.3.7.  http://www.dwheeler.com/oss  fs  refs.html 

Página  que  ofrece  enlaces  a  páginas  relacionadas  con  el  software 
Open  Source  y  el  Free  Software(OSS/FS). 


Figura  7 
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Como  podemos  ver,  los  recursos  documentales  son  muchos.  El  inge¬ 
niero  en  SL  debe  saber,  al  menos,  dónde  encontrar  documentación 
sobre  las  principales  aplicaciones  que  integran  los  proyectos  de  soft¬ 
ware  libre,  para  lo  cual  lo  más  cómodo  es  dirigirse  al  Linux  Docu- 
mention  Project  y  más  concretamente  a  su  zona  traducida  al  español, 
además  de  conocer  aquellas  que  le  pueden  ayudar  a  resolver  pro¬ 
blemas  de  legislación  o  asimilación  de  estándares,  así  como  webs  de 
propósito  general  y  de  preguntas  más  corrientes. 


8.4.  Comunidad 


Con  la  presentación  de  éstos,  intentamos  dar  únicamente  una  refe¬ 
rencia  a  la  gran  cantidad  de  foros  sobre  distintos  temas  relaciona¬ 
dos  con  el  software  libre.  Las  webs  que  detallamos  son,  en  el  caso 
de  las  relacionadas  con  preguntas  y  respuestas,  recopilaciones  de 
listas  de  distribución  de  gran  cantidad  de  temas.  Por  otro  lado, 
mostramos  una,  en  la  que  lo  que  se  pu bl icita  es  el  propio  desarro¬ 
llador,  donde  puede  relacionarse  con  otros  desarrolladores  am¬ 
pliando  su  red  de  relaciones. 


8.4.1.  http://www.mail-archive.com 

Esta  página  proporciona  un  servicio  de  acceso  a  archivos  pertene¬ 
cientes  a  listas  de  correos  públicas.  Además,  permite  añadir  nuevas 
listas  para  incluir  sus  archivos  para  futuras  búsquedas. 


Es  un  buen  lugar  para  buscar  información  de  todo  tipo,  incluida  la 
relacionada  con  el  software  libre.  La  comunidad  Linux  dispone  de 
una  gran  cantidad  de  listas  de  correo,  donde  se  resuelven  dudas  y  se 
ponen  en  común  los  desarrollos  y  conocimientos  de  los  usuarios  que 
pertenecen  a  ellas. 
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Welcome 


What  is  it? 

An  easy  to  use  archivíng  serví co  lor  electronic  maillng  lista. 

Read  or  search 

2570  active  lista 

21957007 messages 

as  of  Sunday.  Fetxuary  13. 2005 


<3  FAQ 
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8.4.2.  http://mail.qnu.org/archive/html/ 

La  página  proporciona  todas  las  listas  de  correo  que  pertenecen  a 
GNU.  GNU  (GNU  isn't  UNIX)  es  un  proyecto  de  FSF  (Free  Software 
Fundation).  Su  objetivo  es  desarrollar  un  sistema  operativo  basado 
en  UNIX  pero  con  la  idea  del  software  libre  de  fondo.  GNU  es  el  es¬ 
tándar  que  siguen  las  nuevas  distribuciones  Linux  para  permitir  una 
integración  máxima  dentro  de  los  sistemas  operativos  existentes  bajo 
el  epígrafe  "free  software". 


La  información  a  la  que  accedemos  desde  esta  página  nos  ayudará 
a  entender  mejor  la  filosofía  GNU  y  además  nos  servirá  de  apoyo  en 
el  caso  de  intentar  hacer  desarrollo  de  software  libre. 
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Figura  9 


3  He  Hímjw  (U  G«cl»  (5)  j mjnual.doc  -  |¿J  ftursc» _proj¿J  recuto» _pro<  im—i  ífcí  15:52  *jl  -J. 

8.4.3.  httD://www.advoaato.ora/ 

Advogato,  según  su  "mission  statement"  es  un  sitio  para  la  comuni¬ 
dad  de  desarrolladores  Open  Source.  El  sitio,  con  un  diseño  muy 
simple,  ofrece  la  posibilidad  de  crear  una  cuenta  a  cualquier  persona 
y  dispone  de  un  interesantísimo  sistema  de  certificación  intrausuarios 
llamado  trust-metric,  que  permite  que  los  usuarios  del  sitio  "certifi¬ 
quen"  a  otros  usuarios.  Básicamente  una  evolución  web-style  del  vie¬ 
jo  tema  de  la  validación  de  usuarios  en  los  BBS. 

La  opción  más  interesante  del  sitio  consiste  en  crear  un  "diario"  pú¬ 
blico  que  otros  pueden  leer  y  comentar,  donde  los  desarrolladores 
pueden  compartir  su  día  a  día.  Es  interesante  leer  cómo  trabajan  los 
demás  o  qué  piensan,  y  sirve,  eventualmente,  como  una  base  de  lo 
que  uno  ha  ido  haciendo  a  lo  largo  del  tiempo. 

Otras  opciones  son  crear  "proyectos",  establecer  relaciones  entre 
proyectos  y  usuarios,  certificar  usuarios  y  postear  artículos  (se  requie¬ 
re  un  cierto  nivel  de  certificación). 

El  diseño  simple  y  sobrio  y  la  seriedad  general  del  sitio  lo  hacen  más 
que  recomendable.  El  software  con  el  que  está  hecho  el  sitio  está  dis¬ 
ponible,  es  un  modulo  en  "C"  para  Apache,  algo  realmente  curioso. 
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Nota 


http://www.advogato.org/ 

trust-metric.html 


Figura  10 
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CodeCon  2005  approaching  _ 

Posted  9  Feb  2005  by  Bram 

CodeCon  2005  ¡s  aboul  lo  begin,  going  from  feb  1 1-13.  We’ve  gol  lots 
>!'!""■  t 1 1  «“><■  1 1 1 . >  ihis  year.  and  it'sonly  S80  for  three  days 

Read  more...(1  reply) 

Fund  Drive  -  An  Auction  To  Protect  Madidi  and  Help 
Save  a  Treasured  Wilderness! 

Posted  8  Feb  2005  by  badvogato 

Ok.  folks.  Here's  a  chance  lo  grab  a  piecc  of  ¡magination  that  lime  we 
sharcd  on  advogato  shall  be  remembered  even  if  all  human  perished 
bul  monkeys  live  on  and  rule,  (not  exactly  as  was  wrilten  in  ihe  Bible.  or 
isit?) 

Anyway.  Wildlife  Conservalion  Socieiy  is  auctioning  Ihe  right  lo  ñame 
an  unidentified  lili  monkey  on  charityfolks.com. 


Iu~  _ 

f¿  1  >•  Vanager  «JÍGecko  (5)  _]  manual.doc  -  |¿J  reo*sos_pio>)  recursos  _pro<  tu 


Welcome  lo  Advogalo. 
ihe  free  software 
developers  advócale. 
The  goal  of  Ihe  site  is 
lo  serve  as  a 
community  resource 
for  free  software 
developers  around 
the  world.  as  well  as  a 
research  teslbed  for 
work  on  group  trusl 
melrics. 

Here's  Ihe  mission 


Curious  how  the  irust 
works? 

Advogato  is  devoted 
lo  the  public  good 
through  its  support  of 
free  software. 


fcí  15  55  41  13 


8.5.  Albergar  proyectos  de  software  libre 
(sourceforce) 

Con  este  apartado  se  intenta,  a  través  de  Sourceforge  -el  espacio  de 
albergado  y  gestión  de  proyectos  más  importante  del  momento-, 
mostrar  la  forma  como  habitualmente  se  crea  una  cuenta  de  proyec¬ 
to,  además  de  las  opciones  y  facilidades  que  nos  ofrece  este  sitio. 

La  operativa,  tanto  de  creación  de  proyecto  como  las  utilidades  que  nos 
dan,  son  similares.  La  única  barrera  puede  ser  el  idioma,  para  la  que 
presentamos  la  alternativa  hispanohablante,  software-libre.org. 


8.5.1.  Sourceforqe.net 

Sourcefoge.net  es  la  forja  por  excelencia.  En  él  se  crean  y  albergan 
más  del  80%  de  los  proyectos  de  software  libre  existentes. 

Aunque  como  su  nombre  indica  es  una  incubadora  de  proyectos,  és¬ 
tos  casi  nunca  desaparecen  de  Sourceforge  al  alcanzar  la  mayoría 
de  edad,  sino  que  siguen  conservando  las  páginas  iniciales  del  pro¬ 
yecto,  aunque  tengan  su  propio  dominio  y  Homepage  en  el  futuro. 
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Su  principal  problema,  aunque  para  cualquier  programador  que  se 
precie  no  debería  serlo,  es  el  idioma.  Su  idioma  principal  es  el  inglés, 
aunque  podamos  albergar  un  proyecto  en  español  u  otro,  las  herra¬ 
mientas,  utilidades  y  navegación  del  portal  están  en  inglés. 

En  este  capítulo  repasaremos  la  totalidad  de  Sourceforge.  Crearemos 
un  usuario  y  un  proyecto  y  una  vez  creado,  daremos  un  paseo  por  las 
utilidades  que  Sourceforge  pone  a  disposición  del  programador. 


8.5.2.  Creación  de  una  cuenta  de  usuario 

La  creación  de  una  cuenta  de  usuario  de  Sourceforge  es  sencilla,  en 
primera  instancia  sólo  se  nos  pide  una  contraseña  y  una  dirección  de 
correo  electrónico. 

En  un  segundo  paso  debemos  introducir  un  nombre  de  usuario  para 
el  acceso  al  portal  y  un  nombre  publicitario  o  nombre  con  el  que 
aparecerá  nuestro  usuario  y  los  proyectos  que  alberguemos  bajo  este 
nombre. 

Además,  se  nos  pregunta  el  idioma  del  proyecto  y  si  deseamos  reci¬ 
bir  correo  de  las  listas  de  actualización  y  del  resto  de  comunidades. 

Tras  realizar  el  registro  completo,  recibimos  en  nuestro  correo  un 
mail  de  confirmación  que  nos  indica  que,  si  queremos  terminar  nues¬ 
tro  registro,  pulsemos  sobre  el  enlace  que  aparece  bajo  el  epígrafe 
"[...]  ptease  access  the  following  URL:" 

Al  mismo  tiempo  que  recibimos  el  correo  de  confirmación,  termina 
el  proceso  de  registro  con  una  página  en  la  que  se  nos  detallan  los 
datos  de  nuestro  usuario:  nombre  de  la  cuenta  de  usuario,  alias  para 
la  cuenta  de  creación,  por  ejemplo,  usuario@dominio.com,  cuenta  de 
Sourceforge,  la  cual  es  un  alias  a  nuestra  cuenta  real,  la  página  en  la 
que  podemos  modificar  nuestros  datos  de  usuario  y  en  la  que  podemos 
encontrar  información,  documentación  y  respuestas  a  nuestras  pregun¬ 
tas  más  corrientes. 

Una  vez  creada  la  cuenta,  podemos  acceder  a  ella  con  nuestro  nom¬ 
bre  de  usuario  y  nuestra  contraseña.  Esta  última  la  introdujimos  en 
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el  primer  paso  de  creación  de  la  cuenta.  Además,  desde  esta  misma 
podemos  solicitar  nueva  contraseña  en  caso  de  olvido  o  crear  una 
nueva  cuenta. 


En  el  momento  del  acceso  se  abre  nuestra  página  de  usuario,  donde 
aparece  toda  la  información  del  mismo,  si  tenemos  o  no  proyectos 
en  curso  o  pendientes  de  activación,  si  se  han  realizado  donativos  a 
nuestro  usuario  y  si  tenemos  alguna  pregunta  pendiente  con  el  cen¬ 
tro  de  apoyo  entre  otras. 


8.5.3.  Alta  de  nuevo  provecto 


La  primera  vez  que  creamos  una  cuenta,  no  se  nos  pide  que  in¬ 
troduzcamos  un  nombre  real  para  poder  activarla,  pero  este  pro¬ 
ceso  sí  que  es  necesario  en  el  caso  de  querer  dar  de  alta  un 
proyecto  nuevo. 


Por  otra  parte,  y  dependiendo  del  tipo  de  usuario  que  hemos  creado 
y  del  tipo  de  licencia  que  utilizamos,  puede  ser  interesante  que  habi¬ 
litemos  los  donativos;  para  hacerlo,  debemos  disponer  de  cuenta  en 
PayPal.  Este  sistema  permite  transferir  fondos  a  una  cuenta  de  usua¬ 
rio  sin  necesidad  de  utilizar  tarjeta  de  crédito. 


Cualquiera  que  juzgue  útil  nuestro  proyecto  podrá  donar  la  cantidad 
de  dinero  que  crea  oportuna  y  ayudarnos  así  a  mantenerlo. 


En  la  creación  de  un  nuevo  proyecto,  aunque  no  es  necesario  que 
éste  sea  libre,  se  nos  indica,  por  si  no  lo  sabemos,  qué  ventajas  tie¬ 
ne  el  SL  y  la  creación  de  este  tipo  de  proyectos  frente  al  software 
propietario. 


El  primer  paso  es  indicar  el  tipo  de  proyecto  que  queremos  publicar, 
en  nuestro  caso,  documentación.  Por  otro  lado,  se  nos  pregunta  si 
hemos  entendido  el  significado  de  la  definición  de  Open  Source. 
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Figura  1 1 .  Esquema  del  proceso  de  registro  de  un  proyecto 
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|  Software  Group  j^J 
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SF.net  Subscríption  Languages 


•  Manage  Subscnption 

•  Advanced  Search 

•  Direct  Download 

•  Prionty  Tech  Support 

•  Project  Monitormg 

SF.net  Resources 
Sito  Docs 

Site  Status  (02/09) 
SF.net  Supporters 
Compile  Farm 
Foundnes 

Project  Help  wanted 
New  Releases 

Cet  Support 

Site  Sponsors 


Project  Registration:  Registeríng  a  project 

Progress:  20%  completed 

Time  to  The  process  of  submittmg  a  project  registration  on 

complete  SourceForge.net  will  generally  require  between  1S  minutes  and  30 

minutes. 

The  descnption  for  your  project  (the  'registration  descnption*) 
must  be  submitted  m  English.  We  cannot  accept  descnptions 
wntten  in  other  languages. 

Review  Process  Project  registrations  are  reviewed  by  a  real  human  before  they  are 
approved.  Projects  are  reviewed  dunng  business  hours  (9AM-SPM, 
Monday  through  Fnday). 

Project  Approval  Projects  are  typically  approved  or  rejected  withm  two  busmess 
days.  You  will  receive  notification  of  our  decisión  vía  your  My 
SF.net  Projects  page.  Dunng  the  registration  process,  you  will  be 
asl.ed  to  venfy  that  the  email  address  we  have  on-file  for  your 
account  is  still  correct;  it  is  cmportant  that  we  have  a  vabd 
address  on-file  for  your  account  in  the  event  that  we  need  to 
reach  you  for  administrativo  purposes  later,  and  to  supply  you 
with  a  copy  of  the  detads  for  the  project  you  are  registenng, 


Support 


Steps  in  this 
process 


■  '!  F  M 

|  E*X«rpm«  Edidon  | 


Most  Active 


If  you  have  questions  about  this  process,  or  about  the  hostmg  of 
your  project  (i.e.  does  my  project  qualify  for  hostmg?),  contact 
the  SourceForge.net  team  by  submittmg  a  Support  Request, 
preferrably  before  you  submit  a  hostmg  request. 

The  followmg  steps  are  involved  in  this  project  registration 
process: 

1.  Hosting  Information 

2.  Registenng  a  project  (current  step) 

3.  Terms  of  Use  Agreement 

4.  Hosting  requirements 

5.  Project  tícense  detaiis 

6.  Project  descnption  detaiis 

7.  Project  ñame  detaiis 

8.  Final  review 

9.  Submission  completed 


Enterprise  Collaboratic 


3  FCKeditor 


Previous  page  [  Next  page  | 


BE 


na 


Antes  de  continuar,  se  nos  indican  los  pasos  que  vamos  a  seguir  y  en 
primer  lugar  el  tiempo  que  nos  tomará  este  proceso  de  alta  de  proyecto. 


Aceptamos  los  términos  y  condiciones  para  albergar  un  proyecto  en 
Sourceforge  e  incluimos  los  datos  de  la  licencia.  Si  nuestro  proyecto 
se  desarrolla  bajo  una  licencia  que  no  aparece  en  el  listado,  por 
ejemplo,  GFDL,  escribimos  una  breve  descripción  de  la  misma  en  el 
recuadro  inferior. 

El  siguiente  paso  es  escribir  una  descripción  pública  y  otra  para  su 
registro  en  la  base  de  datos  de  Sourceforge. 

Por  último  se  nos  pide  que  repasemos  todos  los  datos  introducidos 
por  si  hubiese  algún  error. 


Tras  este  repaso,  recibimos  un  correo  que  confirma  la  creación  del 
proyecto  y  el  paso  a  aprobación,  es  decir,  el  proyecto  será  revisado 
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por  personal  de  Sourceforge  y  albergado  definitivamente.  Este  pro¬ 
ceso  suele  durar  dos  o  tres  días  hábiles. 


8.5.4.  Utilidades  que  Sourceforge  pone  a  disposición 
de  los  usuarios  de  un  provecto 

Una  vez  terminado  el  proceso  de  creación  de  un  proyecto,  se  ponen 
a  disposición  del  administrador  del  proyecto  una  serie  de  herramien¬ 
tas  que  permitirán  el  correcto  trabajo  colaborativo  de  los  diferentes 
partícipes  del  mismo: 

En  su  barra  de  herramientas  podemos  hacernos  una  idea  de  lo  que 
se  nos  ofrece. 


Figura  1 2.  Barra  de  herramientas  de  proyecto 

Project:  Gaim:  Summary 

Summary  |  Admm  |  Home  Pag* *  |  Forums  |  TracMr  I  Bug*  I  Support  |  Patches  |  bfe  |  U*ts  |  Screenshots  |  N«*s  |  CVS  |  Files  | 

En  este  caso  es  para  el  proyecto  Gaim,  que  proporciona  el  desarrollo 
de  un  cliente  de  mensajería  instantánea  compatible  con  casi  todos 
los  servidores  disponibles. 


Como  vemos,  se  nos  muestra  un  sumario  del  proyecto  con  su  des¬ 
cripción,  áreas  públicas  disponibles  y  últimas  noticias. 


Figura  13.  Descripción  del  proyecto 


Gaim  is  a  GTK2-based  instant  messenger  application.  It  supports  múltiple  protocols  vía  modules,  mdudmg  A1M,  ICQ,  Yahoo I,  MSN, 
Jabber,  IRC,  Napster,  Gadu-Gadu  and  Zephyr.  It  has  many  common  features  found  in  other  dients,  as  well  as  many  un*que  featur 

OKaS?  ;GMOME  Foundry 


Project  of  the  month  for:  Octob 


•  Development  Status:  S 

•  Intended  Audience  En< 

•  License  GNU  General  P 

•  Operating  System:  All  3 

•  Programming  Language: 

•  Tepe,  aol  Instant  Meí 

•  User  lnterface:  Gnome, 


Project  UNIX  ñame:  gaim 
Registered:  1999-11-13  23:Sl 

Activity  Percentile  (last  weel  ):  100% 


4 


Arriba  podemos  ver  la  descripción  del  proyecto.  Y  en  las  siguientes, 
las  áreas  públicas  disponibles. 
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Figura  14.  Áreas  públicas  disponibles 


Public  Areas 


Project  Home  Page 
Tracker 

-  Bugs  (  605  open  /  9035  total  ) 

Bug  Tracking  System 

-  Support  Requests  (  64  open  /  662  total  ) 

Tech  Support  Tracking  System 

-  Patches  (  69  open  /  1920  total  ) 

Patch  Tracking  System 

-  Feature  Requests  (  1532  open  /  2524  total  ) 

Feature  Request  Tracking  System 

-  Plugins  (  61  open  /  266  total  ) 

Plugin  Tracking  System 

-  gtk-bugs  (  112  open  /  147  total  ) 

Gtk  only  wants  reports  with  non-gaim  test  cases. 

-  Rejected  Patches  (  3  open  /  4  total  ) 

Patches  not  accepted  to  the  Gaim  core,  but  that  might  be  useful  to  someone. 

-  Translations  (  8  open  /  10  total  ) 

A  tracker  for  updated  .po  files 

Public  Forums  (  12177  messages  in  1  forums  ) 

Mailing  Lists  (  9  total  ) 


Screenshots 

CVS  Repository  (  13,529  commits,  3,435  adds  ) 

-  Browse  CVS 


Y  también  las  últimas  noticias: 


Aparecen  listadas  por  fecha  las  últimas  versiones  y  adiciones  al 
proyecto. 
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Figura  15.  Últimas  noticias 


Latest  News 


Gaim  0.60  released  (Linux  and  win32) 
robflynn  -  2003-04-05  18:01 

(11  Comments)  [Read  More/Comment] 

Gaim  v0.60-alpha3  for  win32 
robflynn  -  2002-11-08  15:46 

(5  Comments)  [Read  More/Comment] 

Gaim  vO.59.6  released 

robflynn  -  2002-11-08  15:43 

[Read  More/Comment] 


Gaim  vO.54  Release;  Direct  IM  Image  Support 
robflynn  -  2002-03-15  21:43 

(10  Comments)  [Read  More/Comment] 

Gaim  v0.49  released! 

robflynn  -  2001-11-29  22:19 

[Read  More/Comment] 


Applet  RPMS  available 

robflynn  -  2001-06-05  05:49 

(2  Comments)  [Read  More/Comment] 

GAIM  0.11.0pre5  Has  been  released! 
robflynn  -  2001-02-27  00:37 

(1  Comment)  [Read  More/Comment] 


0.11.0pre2 

robflynn  -  2000-12-04  22:20 

[Read  More/Comment] 


O.ll.Oprel 

robflynn  -  2000-12-04  08:16 

(1  Comment)  [Read  More  Comment] 


0.10.2  -  wahoo 

robflynn  -  2000-10-07  21:44 

[Read  More/Comment] 


[News  archive] 
[Submit  News] 


Zona  de  descargas  de  últimas  versiones: 


Tanto  de  versiones  finales  como  de  utilidades  o  software  adicional 
necesario. 


Figura  16.  Zona  de  descargas 

latest  File  Reloases 


Versión 


Ojio 
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Pac! age 
gaim 

CTK  ♦  for  Windows 


1.1.2 


January  21.  2005 
Januarv  21,  2005 


Notes  /  Momtor 
#  -0 
*  -0 


Zona  de  foros 


Figura  1 7.  Foros 


Discussion  Forums:  Open  Discussion 

Monitor  tliis  Forum  |  S  Stop  Monitoring  this  Forum  |  ^  Save  Place  |  Adniin  | 
Search 


|  Open  Discussion  |  Ultímate  3  |  Show  25  3 

Topic 

CD  need  some  help  with  sonie  options  and 
design 

CD  No  protocols 
D  Cannot  connect  to  MSN 


Change  View  | 

Topic  Starter  Replíes 

naima-online  0 

silverspurg  8 

dmulligan  27 


Last  Post 

2005-02-14 

12:39 

2005-02-14 

11:07 

2005-02-14 

04:52 


Seguimiento  de  áreas  de  trabajo,  así  como  zona  de  errores  y  par¬ 
ches.  Todos  ellos  incluidos  como  opciones  visibles  de  un  completo 
sistema  de  control  de  versiones. 

Por  lo  tanto,  en  Sourceforge  no  sólo  incluimos  nuestro  proyecto,  sino 
que  nos  dan  el  espacio  necesario  para  albergarlo  y  multitud  de  he¬ 
rramientas  que  ayudan  a  los  programadores  a  colaborar.  Comuni¬ 
cándose  con  los  foros,  enviando  sus  trabajos  con  el  CVS,  además  de 
pequeñas  utilidades  como  la  redirección  web  para  nuestro  proyecto 
o  la  redirección  del  correo  electrónico  de  nuestra  cuenta  de  Source¬ 
forge  a  nuestra  cuenta  personal. 

Todo  esto  sólo  bajo  la  recomendación  de  desarrollar  nuestro  proyec¬ 
to  como  un  proyecto  abierto  donde  se  permita  la  colaboración  de 
otros  programadores  y  bajo  un  sinfín  de  licencias  abiertas. 

Desde  hace  relativamente  poco  se  ha  añadido  a  Sourceforge  la  op¬ 
ción  power,  en  la  que  por  un  precio  asequible  se  ofrecen  al  usuario 
ciertos  servicios  no  disponibles  en  la  gratuita  como: 

•  Acceso  a  utilidades  de  búsqueda  avanzada  para  los  proyectos  de 
Sourceforge 

•  Soporte  técnico  prioritario 

•  Seguimiento  de  proyectos 

•  Descargas  directas  de  software  sin  pasar  por  servidores  de  réplica 
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8.5.5.  Software-libre.org 


El  homónimo  español  de  Sourceforge  es  software-libre.org.  Este  por¬ 
tal  utiliza  el  mismo  software  que  Sourceforge  y  alberga  proyectos 
gratuitamente  pero  en  español. 

Es  una  opción  muy  válida  para  todos  aquellos  desarrolladores  his¬ 
panos  que  quieran  publicitar  proyectos  en  su  zona  de  influencia  o 
que  no  conozcan  el  idioma  inglés. 


Figura  18.  Principal  de  software-libre.org 


Su  lista  de  proyectos  es  mucho  menor  que  la  de  Sourceforge  y  tam¬ 
bién  es  mucho  más  ¡oven.  Nació  en  el  2003,  por  lo  que  su  desarrollo 
ha  sido  mucho  menor. 
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Figura  1  9.  Proyectos  disponibles 


El  proceso  de  registro  de  usuarios  y  proyectos  es  muy  similar  al  de 
Sourceforge. 

Esta  puede  ser  una  buena  opción,  aunque  muy  localizada,  para  al¬ 
bergar  nuestros  proyectos.  De  momento  su  uso  es  limitado  y  casi  lo¬ 
calizado  en  España,  pero  el  sistema  está  creciendo  continuamente. 
Esperemos  que  en  poco  tiempo  pueda  ser  referencia  hispana  como 
forja  de  proyectos  libres. 


8.5.6.  Publicitar  provectos  de  software  libre  v  obtener 
notoriedad 


Cada  día  más,  es  necesario  -tanto  para  encontrar  colaboradores  como 
patrocinadores-  publicitar  nuestros  proyectos  con  la  herramientas  ade¬ 
cuadas.  Casi  ninguna  cumple  todas  las  expectativas,  pero  sí  que  pode¬ 
mos  lograr,  usando  varias  de  ellas,  el  objetivo  deseado. 

La  más  usada  de  todas  para  publicitar  proyectos  de  software  y  rela¬ 
cionarse  con  otros  desarrolladores  es  Freshmeat.net. 

Vamos  a  introducirnos  en  esta  herramienta  para  más  adelante  mos¬ 
trar  otra  de  apoyo  que  completará  nuestro  objetivo. 


Software  libre 


8.5.7.  Freshmeat.net 


Figura  20.  Página  de  inicio 
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Como  podemos  ver  en  su  página  principal,  con  Freshmeat  consegui¬ 
remos  publicitar  nuestro  proyecto  software  haciendo  que  éste  aparezca 
en  la  lista  de  su  página  principal,  de  forma  que  tanto  desarrolladores 
interesados  en  participar,  como  usuarios  interesados  en  usarlo  puedan 
acceder  a  él  sin  necesidad  de  buscarlo. 


Proporciona  un  control  de  versiones  que  nos  permite  ir  añadiendo 
sucesivas  revisiones  y  poder  comprobar  su  historial,  al  mismo  tiempo 
que  nos  pone  en  contacto  con  otros  desarrolladores  de  proyectos  pa¬ 
recidos  con  los  que  poder  establecer  cooperaciones. 

Vamos  a  crear  una  cuenta  de  usuario  y  a  seguir  el  proceso  de  crea¬ 
ción  de  un  proyecto  ficticio: 

•  La  creación  de  una  cuenta  de  usuario  es  sencilla.  Sólo  se  nos  so¬ 
licita  un  nombre  de  usuario,  un  nombre  de  proyecto  que  será  vi¬ 
sible  en  la  lista  principal  de  Freshmeat,  una  dirección  de  correo  y 
una  contraseña.  Como  dato  opcional  podemos  introducir  el  sitio 
web  del  proyecto. 
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•  Una  vez  creado  el  usuario,  recibimos  un  mensaje  de  confirmación 
y  activación.  Como  en  el  caso  de  Sourceforge,  debemos  pulsar 
sobre  el  enlace  para  activar  nuestra  cuenta. 

Una  vez  creado  el  usuario  desde  su  página  principal,  podemos  rea¬ 
lizar  las  tareas  necesarias  para  la  administración  de  nuestra  cuenta 
y  sus  preferencias  personales: 


Figura  21 .  Administración  de  preferencias  de  proyecto 
y  personales 


Y  también  para  la  creación  de  un  nuevo  proyecto  de  visibilidad.  To¬ 
das  estas  opciones  podemos  realizarlas  desde  dos  menús: 

•  El  principal 


Figura  22.  Menú  principal 


h<?me  I  faCBMfflB  I  articles  |  cpntact  |  chat  |  submit  I  fací  I  QS^SlS-tíSi:  I  about  I 

stats  |  scoop 


Desde  el  que  podemos  añadir  un  nuevo  proyecto  o  acceder  a  infor¬ 
mación  general  del  portal. 
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•  Y  el  de  usuario 


Figura  23.  Menú  de  usuario 


home  I  filters  I  friends  I  inbp*  I  passvvord  I  preferentes  I  stored  seerches  I 
subscriPtions  |  loaout 


Desde  donde  podemos  añadir  filtros  para  ver  sólo  aquellos  proyec¬ 
tos  que  nos  interesen,  acceder  a  los  mensajes  que  nos  puedan  haber 
enviado  otros  usuarios,  a  las  preferencias  de  nuestro  usuario,  a  las 
estadísticas,  etc. 

La  opción  de  amigos  es  realmente  interesante,  ya  que  desde  ella 
mantenemos  nuestra  lista  de  contactos  de  Freshmeat,  una  de  las  cosas 
más  importantes  a  la  hora  de  publicitar  nuestro  proyecto  y  e-colaborar 
con  el  resto  de  la  comunidad. 


¿Como  añadir  un  nuevo  proyecto?  Sólo  tenemos  que  pulsar  en  el  en¬ 
lace  submit  del  menú  principal  y  podremos  hacerlo: 


Figura  24.  Creando  un  nuevo  proyecto:  información  general 


Como  vemos  es  sencillo,  sólo  debemos  escoger  el  sistema  operativo 
del  mismo,  un  nombre  completo  de  proyecto,  su  nombre  corto,  su 
descripción  completa  y  su  descripción  corta. 
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Añadir  el  proyecto  a  una  categoría  y  repasar  los  datos  que  hemos  in¬ 
troducido  como  muestra  la  siguiente  imagen. 


Figura  25.  Datos  de  nuestro  proyecto 


Con  estos  tres  simples  pasos  y  esperando  la  confirmación  del  admi¬ 
nistrador  del  sitio,  que  suele  tardar  unos  dos  días,  dispondremos  de 
nuestro  proyecto  creado  y  listo  para  mandar  comunicaciones  y  avisos 
de  nuevas  versiones  o  noticias. 


Descripción  funcional  de  Freashmeat 

Desde  el  menú  de  usuario  y  con  un  proyecto  dado  de  alta,  podemos  ac¬ 
ceder  a  la  administración  del  mismo,  mediante  el  menú  de  proyecto: 


Figura  26.  Menú  de  proyecto 

add  release  |  add  branch  |  add  screenshot  |  broken  links  |  chanae  owner 
email  subscribers  |  UpdatS-BBlfiSt  I  uodate  branch  turlst 

Y  a  la  página  principal  del  proyecto  desde  la  que  podemos  ver  los 
subscriptores  a  ese  proyecto,  las  estadísticas  de  visita  sobre  el  mismo, 
una  descripción  y  una  imagen  de  previsualización  de  la  herramienta 
además  de  páginas  de  interés  sobre  la  misma: 
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Figura  27.  Página  principal  del  proyecto 


Aunque  la  mejor  utilidad  ofrecida  por  Freshmeat  es  su  lista  de  desa¬ 
rrolladores  desde  la  que  se  puede  localizar  a  la  practica  totalidad  de 
los  mantenedores  de  los  proyectos  de  software  libre  más  conocidos. 


Figura  28.  Líderes  de  proyecto  conectados 
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8.6.  ¿Cómo  obtener  notoriedad  para  nuestros 
proyectos? 

La  notoriedad  para  nuestros  proyectos  y  para  nosotros  mismos  se 
obtiene  por  regla  general  con  el  trabajo  de  años,  pero  también  con 
ayuda  de  índices  temáticos  y  buscadores. 

Vamos  a  dar  como  orientación  tres  de  ellos,  intentando  además  que 
éstos  sean  referencias  hispanas,  cosa  algo  difícil. 

•  dmoz.com.  Dmoz  es  un  índice  temático  que  intenta  indexar  pági¬ 
nas  adjuntas  a  determinados  epígrafes,  de  modo  que  la  búsque¬ 
da  resulte  mucho  más  natural  y  centrada. 

En  Dmoz  participan  gran  número  de  editores  de  contenido  que  se 
dedican  a  mantener  páginas  de  confianza  dentro  de  epígrafes  de 
confianza,  es  decir,  si  nosotros  sabemos  de  la  existencia  de  una  pá¬ 
gina,  de  la  que  podemos  ser  los  administradores,  podemos  hacer¬ 
nos  editores  de  la  misma  en  una  sección  determinada,  por  ejemplo, 
desarrollo  de  software,  software  libre,  etc.,  de  manera  que  al  man¬ 
tenerla  en  el  índice  la  publicitamos. 


Figura  29.  Principal  de  Dmoz.com 
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•  Contenido  de  un  directorio 


Dentro  del  directorio  computers,  existen  infinidad  de  subdirectorios 
entre  los  que  está  el  de  Open  Source.  Podemos  mantener  nuestro 
proyecto  en  su  interior. 


Figura  30.  Página  de  recursos  sobre  informática 


•  linux.bankhacker.com.  Una  página  española  bastante  consultada 
para  proyectos  es  la  del  grupo  de  desarrolladores  de  bankhacker.  En 
ella  se  pueden  sugerir  productos  de  software  para  incluirlos  en  el  di¬ 
rectorio  de  software  libre  y  Linux. 
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Figura  31.  Principal  de  Bankhacker.com 
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Podemos  sugerir  una  aplicación  en  concreto  rellenando  el  formulario 
que  aparece  tras  pulsar  el  enlace  "sugerir". 


8.7.  Conclusiones 

La  conclusión  final  de  este  apartado  está  clara.  Disponemos  de  mul¬ 
titud  de  recursos  útiles  para  los  ingenieros  del  software  libre.  No  hay 
uno  solo  para  albergar  proyectos,  pero  sí,  uno  más  importante  que 
los  demás.  Lo  mismo  ocurre  con  los  recursos  para  publicitar  nuestros 
proyectos  y  a  nosotros  mismos  como  desarrolladores,  hay  uno  más 
importante,  como  es  Freshmeat,  pero  no  es  el  único,  sino  que  existen 
otros  que  cubren  deficiencias  de  éste. 

Lo  que  está  claro  es  que  cada  día  salen  nuevos  recursos  útiles  y  nue¬ 
vos  proyectos  recomendables,  que  no  siempre  se  publicitan  en  los 
mismos  sitios  y  que  no  siempre  llegamos  a  conocerlos. 

Se  necesita  una  centralización  a  la  que  se  está  llegando  mediante  la 
sindicación  de  contenidos  y  noticias,  pero  aún  quedan  barreras  por 
superar  y  una  de  las  más  patentes  es  la  del  idioma. 
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Hoy  por  hoy,  los  desarrolladores  deben  conocer  el  inglés  para  poder 
dar  a  conocer  sus  proyectos.  Esperemos  que  en  un  futuro  próximo 
los  recursos  principales  también  estén  traducidos  para  acercarlos  a  los 
desarrolladores  no  angloparlantes. 
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Appendix  A.  GNU  Free  Documentatíon  License 


Copyright  (C)  2000,2001,2002  Free  Software  Foundation,  Inc.  59 
Temple  Place,  Suite  330,  Boston,  MA  021 1 1-1307  USA  Everyone  ¡s 
permitted  to  copy  and  distribute  verbatim  copies  of  this  license  docu- 
ment,  but  changing  it  is  not  allowed. 


A.1 .  PREAMBLE 


The  purpose  of  this  License  is  to  make  a  manual,  textbook,  or  other 
functional  and  useful  document  free  in  the  sense  of  freedom:  to 
assure  everyone  the  effective  freedom  to  copy  and  redistribute  it,  with 
or  without  modifying  it,  either  commercially  or  noncommercially. 
Secondarily,  this  License  preserves  for  the  author  and  publisher  a  way 
to  get  credit  for  their  work,  while  not  being  considered  responsible  for 
modifications  made  by  others. 


This  License  is  a  kind  of  copyleft  which  means  that  derivative  works 
of  the  document  must  themselves  be  free  in  the  same  sense.  It 
complements  the  GNU  General  Public  License,  which  is  a  copyleft 
license  designed  for  free  software. 


We  have  designed  this  License  in  order  to  use  it  for  manuals  for  free 
software,  because  free  software  needs  free  documentatíon:  a  free 
program  should  come  with  manuals  providing  the  same  freedoms 
that  the  software  does.  But  this  License  is  not  limited  to  software 
manuals;  it  can  be  used  for  any  textual  work,  regardless  of  subject 
matter  or  whether  it  is  published  as  a  printed  book.  We  recommend 
this  License  principally  for  works  whose  purpose  is  instruction  or 
referen  ce. 
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A.2.  APPLICABILITY  AND  DEFINITIONS 


This  License  applies  to  any  manual  or  other  work,  in  any  médium, 
that  contains  a  notice  placed  by  the  copyright  holder  saying  ¡t  can 
be  distributed  under  the  terms  of  this  License.  Such  a  notice  grants 
a  world-wide,  royalty-free  license,  unlimited  in  duration,  to  use 
that  work  under  the  conditions  stated  herein.  The  Document 
below,  refers  to  any  such  manual  or  work.  Any  member  of  the 
public  ¡s  a  licensee,  and  ¡s  addressed  as  you  You  accept  the  license 
¡f  you  copy,  modify  or  distribute  the  work  in  a  way  requiring 
permission  under  copyright  law. 

A  Modified  Versión  of  the  Document  means  any  work  containing 
the  Document  or  a  portion  of  ¡t,  either  copied  verbatim,  or  with 
modifications  and/or  translated  into  another  language. 

A  Secondary  Section  ¡s  a  named  appendix  or  a  front-matter 
section  of  the  Document  that  deais  exclusively  with  the  relationship 
of  the  publishers  or  authors  of  the  Document  to  the  Document's 
overall  subject  (or  to  related  matters)  and  contains  nothing  that 
could  fall  directly  within  that  overall  subject.  (Thus,  ¡f  the 
Document  ¡s  in  part  a  textbook  of  mathematics,  a  Secondary 
Section  may  not  explain  any  mathematics.)  The  relationship 
could  be  a  matter  of  historical  connection  with  the  subject  or 
with  related  matters,  or  of  legal,  commercial,  philosophical, 
ethical  or  political  position  regarding  them. 

The  Invariant  Sections  are  certain  Secondary  Sections  whose  titles 
are  designated,  as  being  those  of  Invariant  Sections,  in  the  notice 
that  says  that  the  Document  ¡s  released  under  this  License.  If  a 
section  does  not  fit  the  above  definition  of  Secondary  then  ¡t  ¡s  not 
allowed  to  be  designated  as  Invariant.  The  Document  may  contain 
zero  Invariant  Sections.  If  the  Document  does  not  identify  any 
Invariant  Sections  then  there  are  none. 

The  Cover  Texis  are  certain  short  passages  of  text  that  are  listed,  as 
Front-CoverTexts  or  Back-Cover  Texts,  in  the  notice  that  says  that  the 
Document  ¡s  released  under  this  License.  A  Front-Cover  Text  may  be 
at  most  5  words,  and  a  Back-Cover  Text  may  be  at  most  25  words. 
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A  Transparent  copy  of  the  Document  means  a  machine-readable 
copy,  represented  ¡n  a  format  whose  speáfication  ¡s  available  to 
the  general  public,  that  ¡s  suitable  for  revising  the  document 
straightforwardly  with  generic  text  editors  or  (for  ¡mages 
composed  of  pixels)  generic  paint  programs  or  (for  drawings) 
some  widely  available  drawing  editor,  and  that  ¡s  suitable  for  input 
to  text  formatters  or  for  automatic  translation  to  a  variety  of 
formats  suitable  for  input  to  text  formatters.  A  copy  made  ¡n  an 
otherwise  Transparent  file  format  whose  markup,  or  absence  of 
markup,  has  been  arranged  to  thwart  or  discourage  subsequent 
modification  by  readers  ¡s  not  Transparent.  An  image  format  ¡s  not 
Transparent  ¡f  used  for  any  substantial  amount  of  text.  A  copy  that 
¡s  not  Transparent  ¡s  called  Opaque. 

Examples  of  suitable  formats  for  Transparent  copies  inelude  plain 
ASCII  without  markup,  Texinfo  input  format,  LaTeX  input  format, 
SGML  or  XML  using  a  publicly  available  DTD,  and  standard- 
conforming  simple  HTML,  PostScript  or  PDF  designed  for  human 
modification.  Examples  of  transparent  image  formats  inelude  PNG, 
XCF  and  JPG.  Opaque  formats  inelude  proprietary  formats  that  can 
be  read  and  edited  only  by  proprietary  word  processors,  SGML  or 
XML  for  which  the  DTD  and/or  processing  tools  are  not  generally 
available,  and  the  machine-generated  HTML,  PostScript  or  PDF 
produced  by  some  word  processors  for  output  purposes  only. 

The  Tifie  Page  means,  for  a  printed  book,  the  title  page  itself,  plus 
such  following  pages  as  are  needed  to  hold,  legibly,  the  material 
this  License  requires  to  appear  ¡n  the  title  page.  For  works  ¡n  for¬ 
mats  which  do  not  have  any  title  page  as  such,  Title  Page  means 
the  text  near  the  most  prominent  appearance  of  the  work's  title, 
preceding  the  beginning  of  the  body  of  the  text. 

A  section  Entitled  XYZ  means  a  named  subunit  of  the  Document 
whose  title  either  ¡s  precisely  XYZ  or  contains  XYZ  in  parentheses 
following  text  that  translates  XYZ  in  another  language.  (Here  XYZ 
stands  for  a  specific  section  ñame  mentioned  below,  such  as 
Acknowledgements,  Dedications,  Endorsements,  or  History.  To 
Preserve  the  Title  of  such  a  section  when  you  modify  the  Document 
means  that  ¡t  remains  a  section  Entitled  XYZ  according  to  this 
definition. 
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The  Document  may  inelude  Warranty  Disclaimers  next  to  the  notice 
which  states  that  this  License  applies  to  the  Document.  These 
Warranty  Disclaimers  are  considered  to  be  included  by  reference  in 
this  License,  but  only  as  regards  disclaiming  warranties:  any  other 
implication  that  these  Warranty  Disclaimers  may  have  is  void  and  has 
no  effect  on  the  meaning  of  this  License. 


A.3.  VERBATIM  COPYING 


You  may  copy  and  distribute  the  Document  in  any  médium,  either 
commercially  or  noncommercially,  provided  that  this  License,  the 
copyright  notices,  and  the  license  notice  saying  this  License  applies  to 
the  Document  are  reproduced  in  all  copies,  and  that  you  add  no 
other  conditions  whatsoever  to  those  of  this  License.  You  may  not  use 
technical  measures  to  obstruct  or  control  the  reading  or  further 
copying  of  the  copies  you  make  or  distribute.  However,  you  may 
accept  compensation  in  exchange  for  copies.  If  you  distribute  a  large 
enough  number  of  copies  you  must  also  follow  the  conditions  in 
section  3. 

You  may  also  lend  copies,  under  the  same  conditions  stated  above, 
and  you  may  publicly  display  copies. 


A.4.  COPYING  IN  QUANTITY 


If  you  publish  printed  copies  (or  copies  in  media  that  commonly  have 
printed  covers)  of  the  Document,  numbering  more  than  1  00,  and  the 
Document's  license  notice  requires  Cover  Texts,  you  must  endose  the 
copies  in  covers  that  carry,  clearly  and  legibly,  all  these  Cover  Texts: 
Front-Cover  Texts  on  the  front  cover,  and  Back-Cover  Texts  on  the 
back  cover.  Both  covers  must  also  clearly  and  legibly  identify  you  as 
the  publisher  of  these  copies.  The  front  cover  must  present  the  full  title 
with  all  words  of  the  title  equally  prominent  and  visible.  You  may  add 
other  material  on  the  covers  in  addition.  Copying  with  changes 
limited  to  the  covers,  as  long  as  they  preserve  the  title  of  the 
Document  and  satisfy  these  conditions,  can  be  treated  as  verbatim 
copying  in  other  respeets. 
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If  the  required  texts  for  either  cover  are  too  voluminous  to  fit  legibly, 
you  should  put  the  first  ones  listed  (as  many  as  fit  reasonably)  on  the 
actual  cover,  and  continué  the  rest  onto  adjacent  pages. 

If  you  publish  or  distribute  Opaque  copies  of  the  Document 
numbering  more  than  100,  you  must  either  inelude  a  machine- 
readable  Transparent  copy  along  with  each  Opaque  copy,  or  state  in 
or  with  each  Opaque  copy  a  computer-network  location  from  which 
the  general  network-using  public  has  access  to  download  using 
public-standard  network  protocols  a  complete  Transparent  copy  of 
the  Document,  free  of  added  material.  If  you  use  the  latter  option,  you 
must  take  reasonably  prudent  steps,  when  you  begin  distribution  of 
Opaque  copies  in  quantity,  to  ensure  that  this  Transparent  copy  will 
remain  thus  accessible  at  the  stated  location  until  at  least  one  year 
after  the  last  time  you  distribute  an  Opaque  copy  (directly  or  through 
your  agents  or  retailers)  of  that  edition  to  the  public. 

It  is  requested,  but  not  required,  that  you  contact  the  authors  of  the 
Document  well  before  redistributing  any  large  number  of  copies,  to  give 
them  a  chance  to  provide  you  with  an  updated  versión  of  the  Document. 


A.5.  MODIFICATIONS 


You  may  copy  and  distribute  a  Modified  Versión  of  the  Document  under 
the  conditions  of  sections  2  and  3  above,  provided  that  you  release  the 
Modified  Versión  under  precisely  this  License,  with  the  Modified  Versión 
filling  the  role  of  the  Document,  thus  licensing  distribution  and 
modification  of  the  Modified  Versión  to  whoever  possesses  a  copy  of  it. 

In  addition,  you  must  do  these  things  in  the  Modified  Versión: 

•  A.  Use  in  the  Title  Page  (and  on  the  covers,  if  any)  a  title  distinct 
from  that  of  the  Document,  and  from  those  of  previous  versions 
(which  should,  if  there  were  any,  be  listed  in  the  History  section  of 
the  Document).  You  may  use  the  same  title  as  a  previous  versión 
if  the  original  publisher  of  that  versión  gives  permission. 

•  B.  List  on  the  Title  Page,  as  authors,  one  or  more  persons  or 
entities  responsible  for  authorship  of  the  modifications  in  the 
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Modified  Versión,  together  with  at  least  five  of  the  principal 
authors  of  the  Document  (all  of  its  principal  authors,  if  it  has  fewer 
than  five),  unless  they  release  you  from  this  requirement. 

C.  State  on  the  Title  page  the  ñame  of  the  publisher  of  the 
Modified  Versión,  as  the  publisher. 

D.  Preserve  all  the  copyright  notices  of  the  Document. 

E.  Add  an  appropriate  copyright  notice  for  your  modifications 
adjacent  to  the  other  copyright  notices. 

F.  Inelude,  immediately  after  the  copyright  notices,  a  license  notice 
giving  the  public  permission  to  use  the  Modified  Versión  under  the 
terms  of  this  License,  in  the  form  shown  in  the  Addendum  below. 

G.  Preserve  in  that  license  notice  the  full  lists  of  Invariant  Sections 
and  required  Cover  Texts  given  in  the  Document's  license  notice. 

H.  Inelude  an  unaltered  copy  of  this  License. 

I.  Preserve  the  section  Entitled  Hlstory.  Preserve  its  Title,  and  add 
to  it  an  Ítem  stating  at  least  the  title,  year,  new  authors,  and 
publisher  of  the  Modified  Versión  as  given  on  the  Title  Page.  If 
there  is  no  section  Entitled  History  in  the  Document,  create  one 
stating  the  title,  year,  authors,  and  publisher  of  the  Document  as 
given  on  its  Title  Page,  then  add  an  Ítem  describing  the  Modified 
Versión  as  stated  in  the  previous  sentence. 

J.  Preserve  the  network  location,  if  any,  given  in  the  Document  for 
public  access  to  a  Transparent  copy  of  the  Document,  and  likewise 
the  network  locations  given  in  the  Document  for  previous  versions 
it  was  based  on.  These  may  be  placed  in  the  History  section.  You 
may  omit  a  network  location  for  a  work  that  was  published  at  least 
four  years  before  the  Document  itself,  or  if  the  original  publisher 
of  the  versión  it  refers  to  gives  permission. 

K.  For  any  section  Entitled  Acknowledgements  or  Dedicatlons 
Preserve  the  Title  of  the  section,  and  preserve  in  the  section  all  the 


substance  and  tone  of  each  of  the  contributor  acknowledgements 
and/or  dedications  given  therein. 


•  L.  Preserve  all  the  Invariant  Sections  of  the  Document,  unaltered  in 
their  text  and  in  their  titles.  Section  numbers  or  the  equivalent  are 
not  considered  part  of  the  section  titles. 


•  M.  Delete  any  section  Entitled  Endorsements  Such  a  section  may 
not  be  included  in  the  Modified  Versión. 


•  N.  Do  not  retitle  any  existing  section  to  be  Entitled  Endorsements 
or  to  conflict  in  title  with  any  Invariant  Section. 


•  O.  Preserve  any  Warranty  Disclaimers. 


If  the  Modified  Versión  ineludes  new  front-matter  sections  or 
appendices  that  qualify  as  Secondary  Sections  and  contain  no 
material  copied  from  the  Document,  you  may  at  your  option 
designóte  some  or  all  of  these  sections  as  invariant.  To  do  this,  add 
their  titles  to  the  list  of  Invariant  Sections  in  the  Modified  Version's 
license  notice.  These  titles  must  be  distinct  from  any  other  section 
titles. 


You  may  add  a  section  Entitled  Endorsements,  provided  ¡t  contai ns 
nothing  but  endorsements  of  your  Modified  Versión  by  various  parties- 
-for  example,  statements  of  peer  review  or  that  the  text  has  been 
approved  by  an  organization  as  the  authoritative  definition  of  a 
standard. 

You  may  add  a  passage  of  up  to  five  words  as  a  Front-Cover  Text,  and 
a  passage  of  up  to  25  words  as  a  Back-Cover  Text,  to  the  end  of  the 
list  of  Cover  Texts  in  the  Modified  Versión.  Only  one  passage  of  Front- 
Cover  Text  and  one  of  Back-Cover  Text  may  be  added  by  (or  through 
arrangements  made  by)  any  one  entity.  If  the  Document  already 
ineludes  a  cover  text  for  the  same  cover,  previously  added  by  you  or  by 
arrangement  made  by  the  same  entity  you  are  acting  on  behalf  of,  you 
may  not  add  another;  but  you  may  replace  the  oíd  one,  on  explicit 
permission  from  the  previous  publisher  that  added  the  oíd  one. 
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The  author(s)  and  publisher(s)  of  the  Document  do  not  by  this  License 
give  permission  to  use  their  ñames  for  publ icity  for  or  to  assert  or 
imply  endorsement  of  any  Modified  Versión. 


A.6.  COMBINING  DOCUMENTS 


You  may  combine  the  Document  with  other  documents  released 
under  this  License,  under  the  terms  defined  in  section  4  above  for 
modified  versions,  provided  that  you  inelude  in  the  combination 
all  of  the  Invariant  Sections  of  all  of  the  original  documents, 
unmodified,  and  list  them  all  as  Invariant  Sections  of  your 
combined  work  in  its  license  notice,  and  that  you  preserve  all  their 
Warranty  Disclaimers. 

The  combined  work  need  only  contain  one  copy  of  this  License, 
and  múltiple  identical  Invariant  Sections  may  be  replaced  with  a 
single  copy.  If  there  are  múltiple  Invariant  Sections  with  the  same 
ñame  but  different  contents,  make  the  title  of  each  such  section 
unique  by  adding  at  the  end  of  it,  in  parentheses,  the  ñame  of  the 
original  author  or  publisher  of  that  section  if  known,  or  else  a 
unique  number.  Make  the  same  adjustment  to  the  section  titles  in 
the  list  of  Invariant  Sections  in  the  license  notice  of  the  combined 
work. 

In  the  combination,  you  must  combine  any  sections  Entitled  History  in 
the  various  original  documents,  forming  one  section  Entitled  History; 
likewise  combine  any  sections  Entitled  Acknowledgements,  and  any 
sections  Entitled  Dedications.  You  must  delete  all  sections  Entitled 
Endorsements. 


A.7.  COLLECTIONS  OF  DOCUMENTS 


You  may  make  a  collection  consisting  of  the  Document  and  other 
documents  released  under  this  License,  and  replace  the  individual 
copies  of  this  License  in  the  various  documents  with  a  single  copy  that 
is  included  in  the  collection,  provided  that  you  follow  the  rules  of  this 
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License  for  verbatim  copying  of  each  of  the  documents  in  all  other 
respects. 

You  may  extract  a  single  document  from  such  a  collection,  and 
distribute  ¡t  i  nd  i  vi  dual  ly  under  this  License,  provided  you  insert  a 
copy  of  this  License  into  the  extracted  document,  and  follow  this 
License  in  all  other  respects  regarding  verbatim  copying  of  that 
document. 


A.8.  AGGREGATION  WITH  INDEPENDENT  WORKS 


A  compilation  of  the  Document  or  its  derivatives  with  other  sepárate 
and  independent  documents  or  works,  in  or  on  a  volume  of  a  storage 
or  distribution  médium,  is  called  an  aggregate  if  the  copyright 
resulting  from  the  compilation  is  not  used  to  limit  the  legal  rights  of 
the  compilation's  users  beyond  what  the  individual  works  permit. 
When  the  Document  is  included  in  an  aggregate,  this  License  does 
not  apply  to  the  other  works  in  the  aggregate  which  are  not 
themselves  derivative  works  of  the  Document. 


If  the  Cover  Text  requirement  of  section  3  is  applicable  to  these 
copies  of  the  Document,  then  if  the  Document  is  less  than  one  half 
of  the  entire  aggregate,  the  Document's  Cover  Texts  may  be  placed 
on  covers  that  bracket  the  Document  within  the  aggregate,  or  the 
electronic  equivalent  of  covers  if  the  Document  is  in  electronic  form. 
Otherwise  they  must  appear  on  printed  covers  that  bracket  the 
whole  aggregate. 


A.9.  TRANSLATION 


Translation  is  considered  a  kind  of  modification,  so  you  may 
distribute  translations  of  the  Document  under  the  terms  of  section  4. 
Replacing  Invariant  Sections  with  translations  requires  special 
permission  from  their  copyright  holders,  but  you  may  inelude 
translations  of  some  or  all  Invariant  Sections  in  addition  to  the 
original  versions  of  these  Invariant  Sections.  You  may  inelude  a 
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translation  of  this  License,  and  all  the  license  notices  in  the  Document, 
and  any  Warranty  Disclaimers,  provided  that  you  also  inelude  the 
original  English  versión  of  this  License  and  the  original  versions  of 
those  notices  and  disclaimers.  In  case  of  a  disagreement  between  the 
translation  and  the  original  versión  of  this  License  or  a  notice  or 
disclaimer,  the  original  versión  will  prevail. 

If  a  section  in  the  Document  is  Entitled  Acknowledgements, 
Dedications,  or  Hlstory,  the  requirement  (section  4)  to  Preserve  its  Title 
(section  1)  will  typically  require  changing  the  actual  title. 


A.l 0.  TERMINATION 


You  may  not  copy,  modify,  sublicense,  or  distribute  the  Document 
except  as  expressly  provided  for  under  this  License.  Any  other  attempt 
to  copy,  modify,  sublicense  or  distribute  the  Document  is  void,  and 
will  automatically  terminote  your  rights  under  this  License.  However, 
parties  who  have  received  copies,  or  rights,  from  you  under  this 
License  will  not  have  their  licenses  terminated  so  long  as  such  parties 
remain  in  full  compliance. 


A.l  1.  FUTURE  REVISIONS  OF  THIS  LICENSE 


The  Free  Software  Foundation  may  publish  new,  revised  versions  of 
the  GNU  Free  Documentation  License  from  time  to  time.  Such 
new  versions  will  be  similar  in  spirit  to  the  present  versión,  but 
may  differ  in  detail  to  address  new  problems  or  concerns.  See 
http://www.gnu.org/copyleft/. 

Each  versión  of  the  License  is  given  a  distinguishing  versión  number. 
If  the  Document  specifies  that  a  particular  numbered  versión  of  this 
License  or  any  later  versión  applies  to  it,  you  have  the  option  of 
following  the  terms  and  conditions  either  of  that  specified  versión  or 
of  any  later  versión  that  has  been  published  (not  as  a  draft)  by  the 
Free  Software  Foundation.  If  the  Document  does  not  specify  a  versión 
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number  of  this  License,  you  may  choose  any  versión  ever  published 
(not  as  a  draft)  by  the  Free  Software  Foundation. 


A.1 2.  ADDENDUM:  How  to  use  this  License  for  your 
documents 


To  use  this  License  in  a  document  you  have  written,  include  a  copy  of 
the  License  in  the  document  and  put  the  following  copyright  and 
license  notices  ¡ust  after  the  title  page: 

Copyright  (c)  YEAR  YOUR  ÑAME.  Permission  ¡s  granted  to  copy, 
distribute  and/or  modify  this  document  under  the  terms  of  the 
GNU  Free  Documentation  License,  Versión  1 .2  or  any  later 
versión  published  by  the  Free  Software  Foundation;  with  no 
Invariant  Sections,  no  Front-Cover  Texts,  and  no  Back-Cover 
Texts.  A  copy  of  the  license  ¡s  ¡ncluded  in  the  section  entitled  GNU 
Free  Documentation  License 

If  you  have  Invariant  Sections,  Front-Cover  Texts  and  Back-Cover 
Texts,  replace  the  with. ..Texts.  line  with  this: 

with  the  Invariant  Sections  being  LIST  THEIR  TITLES,  with  the  Front- 
Cover  Texts  being  LIST,  and  with  the  Back-Cover  Texts  being  LIST. 

If  you  have  Invariant  Sections  without  Cover  Texts,  or  some  other 
combination  of  the  three,  merge  those  two  alternatives  to  suit  the 
situation. 

If  your  document  contains  nontrivial  examples  of  program  code,  we 
recommend  releasing  these  examples  in  parallel  under  your  choice 
of  free  software  license,  such  as  the  GNU  General  Public  License,  to 
permit  their  use  in  free  software. 
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